Ports Search

Results 17,45117,460 of 17,773 for comment.zh_CN%3A%E6%8E%A7%E5%88%B6%E5%8F%B0.(0.015 seconds)
net-p2p/gtk-gnutella-1.1.10 (Score: 9.346315E-5)
GTK based Gnutella client
GTK based Gnutella client which supports the standard Gnutella operations. Search, download, file sharing, bandwidth limiting, host caching, as well as some basic statistics. Now with enhanced features, such as PARQ queueing, PFSP, DHT, push-proxies, UPnP, NAT-PMP and others, making it a stable and fully functional graphical gnutella client for *nix systems. An excellent way to find that hidden file on the internet that you know exists but standard search engines do not seem to carry. IRC: #gtk-gnutella on freenode.net
net-p2p/ktorrent-4.3.1 (Score: 9.346315E-5)
BitTorrent client for KDE
KTorrent is a BitTorrent client for KDE. Its main features are: o Download torrent files o Upload speed capping, seeing that most people can't upload infinite amounts of data o Internet searching using The Bittorrent website's search engine o UDP Trackers o Port forwarding with UPnP o IP blocking plugin o Importing of partially or fully downloaded files o Support for distributed hash tables o Protocol encryption o Bandwith scheduling o Directory scanner to automatically load torrents in certain directories o Trackers can be added to torrents o File prioritization for multi file torrents
net-p2p/unworkable-0.53 (Score: 9.346315E-5)
Free BitTorrent Implementation
Unworkable is a BSD-licensed BitTorrent implementation for UNIX written from-scratch in C. It uses libevent for scalable asynchronous networking and the mmap() system call for local data access. Some of the goals of the project include (in no particular order) high code quality, efficiency, simplicity and security. Unworkable is still in an early stage of development, and is far behind most other BitTorrent implementations. However, it is usable for some basic things and the source code is quite minimal(4,000 lines of C compared to rTorrent's 40,000+ of C++).
net/freebsd-tftp-1.0 (Score: 9.346315E-5)
Upcoming replacement for tftp(1) and tftpd(8)
It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option. My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet. Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver. At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers: - Itself (yay!) - The standard FreeBSD tftp client and server - The Fedora Core 6 tftp client and server - Cisco router tftp client - Extreme Networks tftp client It supports the following RFCs: RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm: blksize2 - Block size restricted to powers of 2, excluding protocol headers rollover - Block counter roll-over (roll back to zero or to one) From the tftp program point of view the following things are changed: - New commands: "blocksize", "blocksize2", "rollover" and "options" - Development features: "debug" and "packetdrop" If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.
net/daq-2.0.6 (Score: 9.346315E-5)
Data Acquisition abstraction library for snort 2.9+
Snort 2.9 introduces the DAQ, or Data Acquisition library, for packet I/O. The DAQ replaces direct calls to PCAP functions with an abstraction layer that facilitates operation on a variety of hardware and software interfaces without requiring changes to Snort. It is possible to select the DAQ type and mode when invoking Snort to perform PCAP readback or inline operation, etc. The DAQ library may be useful for other packet processing applications and the modular nature allows you to build new modules for other platforms.
net/jgroups-2.12.0 (Score: 9.346315E-5)
Java toolkit for reliable multicast communication
JGroups is a toolkit for reliable multicast communication. (Note that this doesn't necessarily mean IP Multicast, JGroups can also use transports such as TCP). It can be used to create groups of processes whose members can send messages to each other. The main features include: * Group creation and deletion * Joining and leaving of groups * Membership detection and notification about joined/left/crashed members * Detection and removal of crashed members * Sending and receiving of member-to-group messages (point-to-multipoint) * Sending and receiving of member-to-member messages (point-to-point)
net/jsch-0.1.53 (Score: 9.346315E-5)
Pure Java implementation of SSH2
Sch is a pure Java implementation of SSH2. JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs. JSch is licensed under BSD style license. - Why JSch? Our intension in developing this stuff is to enable users of our pure java X servers, WiredX and WeirdX, to enjoy secure X sessions. Our efforts have mostly targeted the SSH2 protocol in relation to X window system and X11 forwarding. Of course, we are also interested in adding other functionality - port forward, file transfer, terminal emulation, etc.
net/ldapdiff-1.4.1 (Score: 9.346315E-5)
Utility for patching LDAP directories using LDIF files
ldapdiff combines "diff" and "patch" functionality in one application. The difference is that ldapdiff is not designed for use on flat ascii files, it is designed for "patching" ldap directories using ldif files. With ldapdiff it is possible to check every entry/attribute of an ldif file against a running ldap directory. ldapdiff is able to produce ldif delta files in ldap version 3 format, which can be fed, into tools like "ldapmodify", "ldapdelete" etc. ldapdiff is also able to modify, delete and add entries/attributes online.
net/netselect-0.3 (Score: 9.346315E-5)
Ultrafast implementation of ping
netselect is an ultrafast intelligent parallelizing binary-search implementation of "ping." netselect determines several facts about all of the hosts given on the command line, much faster than you would if you tried to use ping and traceroute. For example, if I type: netselect -v ftp.fceia.unr.edu.ar \ ftp.kulnet.kuleuven.ac.be \ ftp.cdrom.com ftp.debian.org \ ftp.de.debian.org It tells me statistics about each of the hostnames I provided, in much less time than doing a whole bunch of traceroutes.
net/nmsg-0.11.2 (Score: 9.346315E-5)
Network message encapsulation system
The NMSG format is an efficient encoding of typed, structured data into payloads which are packed into containers which can be transmitted over the network or stored to disk. libnmsg is the reference implementation of this format and provides an extensible interface for creating and parsing messages in NMSG format. The NMSG format relies on Google Protocol Buffers to encode the payload header. Individual NMSG payloads are distinguished by assigned vendor ID and message type values and libnmsg provides a modular interface for registering handlers for specific message types. libnmsg makes it easy to build new message types using the protobuf-c compiler.