Ports 搜索

This package is a port of TAMU's extract program from NetLogger to look at flow data instead of netlogger data. Blame Larry for it's faults, not TAMU. Blame me for the FreeBSD port, not Larry :-) If you don't already have a good guess what this program does and what data it is looking for, the odds are that it isn't going to be of much help to you. This program only works on Cisco flow data as captured with Mark Fullmer's flowtools package. If you don't have that, get that first, then look at this program. In order for this to compile you will need flowtools from Mark Fullmer's (net-mgmt/flow-tools port).

Nstreams is a program which analyzes the streams that occur on a network. It displays which streams are generated by the users between several networks, and between the networks and the outside. It can optionally generate the ipchains or ipfw rules that will match these streams, thus only allowing what is required for the users, and nothing more. Nstreams can parse the tcpdump output, or the files generated with the -w option of tcpdump. It can also directly sniff the data that occurs on the network. This product was designed by HSC and coded by Renaud Deraison (deraison@cvs.nessus.org), author of the Nessus software (www.nessus.org). It is available for free and under GNU license.

This package provides a suite of modules for managing NetApp's NAS devices, commonly referred to as "filers". This is the first public release of my NetApp Perl API, and although I consider the code to be very stable, the API should be considered experimental. The convention I will be following regarding non-compatible API changes is as follows. I'm using a major.minor.subminor release naming convention, and I will promise to NOT make non-backwards compatible changes between subminor releases. However, in order to allow the API to evolve, it is entirely possible that non-backwards compatible changes will be made between minor releases. IOW, the major.minor release numbers can be considered an API version. Any changes to 1.1.0, 1.1.2, etc. must be backwards compatible with the previous 1.1.* releases. There is no guarantee that 1.2.0 will be 100% backwards compatible, although such changes will be made only when justified. The author does not believe in infinite backwards compatibility.

Litecoin is a peer-to-peer Internet currency that enables instant payments to anyone in the world. It is based on the Bitcoin protocol but differs from Bitcoin in that it can be efficiently mined with consumer-grade hardware. Litecoin provides faster transaction confirmations (2.5 minutes on average) and uses memory-hard, scrypt-based mining proof-of-work algorithm to target the regular computers and GPUs most people already have. The Litecoin network is scheduled to produce 84 million currency units. One of the aims of Litecoin was to provide a mining algorithm that could run at the same time, on the same hardware used to mine bitcoins. With the rise of specialized ASICs for Bitcoin, Litecoin continues to satisfy these goals. It is unlikely for ASIC mining to be developed for Litecoin until the currency is widely used.

microdc is a command-line based Direct Connect client written in C by Oskar Liljeblad and designed to build and run on modern POSIX compatible systems. It uses GNU Readline library for user interaction. Despite the command-line user interface, microdc is quite user friendly and simple to use. microdc2 is a future improvement (fork) of the microdc based on Oskar's code version 0.11.0. After version 0.12.0 the project was renamed to microdc2 on Oskar's request. Features of microdc2 include: - Nearly full support of the original Direct Connect protocol - GNU Readline support for command line editing and history - Sensible tab-completion of commands, user names, local files, remote files, speed names, and connection names - One process per connection for optimal transfer rates - Small memory footprint

The nettest and nettestd commands invoke client and server programs that are used for timing data throughput of vari- ous methods of interprocess communication. For TCP and OSI connections, the nettest program establishes a connec- tion with the nettestd program, and then it does count writes of size bytes, followed by count reads of size bytes. For UDP, the nettest program performs only writes; reads are not performed. The nettestd program, if used with UDP connections, reads the data packets and prints a message for each data packet it receives. The number and size of the reads and writes may not correlate with the number and size of the actual data packets that are trans- ferred; it depends on the protocol that is chosen. If you append an optional k (or K) to the size, count, or bufsize value, the number specified is multiplied by 1024.

OpenNX is an open source drop in replacement for NoMachine's NX client. It is compatible to the original client in that it uses the same syntax for the session configuration files (.nxs files). OpenNX is distributed under the GNU Lesser Public License v2.1. OpenNX is written in C++ and uses the excellent wxWidgets toolkit. Compared to the original client, it also adds some additional features which improve usability: - Ability to use the OpenSC framework to enable SmartCard based authentication for the initial SSH connection. - Ability to use a variety of different proxy types. - Ability to fetch session configuration files via http (read only) - Ability to disable configuration controls by providing a read only configuration file. - Dynamic use of libsmbclient, libcups, libopensc and pulseaudio (no static dependencies). - Uses libjpeg-turbo for speed improvement (if available).

Net::Frame is a fork of Net::Packet. The goal here was to greatly simplify the use of the frame crafting framework. Net::Packet does many things undercover, and it was difficult to document all the thingies. Also, Net::Packet may suffer from unease of use, because frames were assembled using layers stored in L2, L3, L4 and L7 attributes. Net::Frame removes all this, and is splitted in different modules, for those who only want to use part of the framework, and not whole framework. Finally, anyone can create a layer, and put it on his CPAN space, because of the modularity Net::Frame offers. For an example, see Net::Frame::Layer::ICMPv4 on my CPAN space.

Net::Google::SafeBrowsing2 implements the Google Safe Browsing v2 API. The library passes most of the unit tests listed in the API documentation. See the documentation (http://code.google.com/apis/safebrowsing/developers_guide_v2.html) for more details about the failed tests. The Google Safe Browsing database must be stored and managed locally. Net::Google::SafeBrowsing2::Sqlite uses Sqlite as the storage back-end, Net::Google::SafeBrowsing2::MySQL uses MySQL. Other storage mechanisms (databases, memory, etc.) can be added and used transparently with this module. You may want to look at "Google Safe Browsing v2: Implementation Notes" (http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf), a collection of notes and real-world numbers about the API. This is intended for people who want to learn more about the API, whether as a user or to make their own implementation.

This module handles the SOAP protocol. The first implementation is SOAP1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/), which is still most often used. The SOAP1.2 definition (http://www.w3.org/TR/soap12/) is quite different; this module tries to define a sufficiently abstract interface to hide the protocol differences. Be aware that there are three kinds of SOAP: 1. Document style (literal) SOAP, where there is a WSDL file which explicitly types all out-going and incoming messages. Very easy to use. 2. RPC style SOAP literal. The WSDL file is not explicit about the content of the messages, but all messages must be schema defined types. 3. RPC style SOAP encoded. The sent data is nowhere described formally. The data is transported in some ad-hoc way.