Ports Search

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.

Matrix is an ambitious new ecosystem for open federated Instant Messaging and VoIP. The basics you need to know to get up and running are: * Everything in Matrix happens in a room. Rooms are distributed and do not exist on any single server. Rooms can be located using convenience aliases like #matrix:matrix.org or #test:localhost:8448. * Matrix user IDs look like @matthew:matrix.org (although in the future you will normally refer to yourself and others using a 3PID: email address, phone number, etc rather than manipulating Matrix user IDs) Synapse is currently in rapid development, but as of version 0.5 we believe it is sufficiently stable to be run as an internet-facing service for real usage!

A pure Python network address representation and manipulation library. netaddr provides a Pythonic way of working with: - IPv4 and IPv6 addresses and subnets - MAC addresses, OUI and IAB identifiers, IEEE EUI-64 identifiers - Arbitrary (non-aligned) IP address ranges and IP address sets - Various non-CIDR IP range formats such as nmap and glob-style formats Included are routines for: - Generating, sorting and summarizing IP addresses and networks - Performing easy conversions between address notations and formats - Detecting, parsing and formatting network address representations - Performing set-based operations on groups of IP addresses and subnets - Working with arbitrary IP address ranges and formats - Accessing OUI and IAB organisational information published by IEEE - Accessing IP address and block information published by IANA API documentation for the latest release is available here: https://pythonhosted.org/netaddr/

tcpmssd was written by Ruslan Ermilov <ru@FreeBSD.org> based on work done by Patrick Bihan-Faou <patrick@mindstep.com>. tcpmssd is a divert(4) program that adjusts outgoing TCP data so that the requested segment size is not greater than the amount allowed by the interface MTU. This is necessary in many setups to avoid problems caused by routers that drop ICMP Datagram Too Big messages. Without these messages, the originating machine sends data, it passes the rogue router then hits a machine that has an MTU that is not big enough for the data. Because the IP Don't Fragment option is set, this machine sends an ICMP Datagram Too Big message back to the originator and drops the packet. The rogue router drops the ICMP message and the originator never gets to discover that it must reduce the fragment size or drop the IP Don't Fragment option from its outgoing data.

tcptraceroute is a traceroute implementation using TCP packets. The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached. By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination. The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination. However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.

tcptraceroute is a traceroute implementation using TCP packets. The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached. By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination. The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination. However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.

xmlrpc-epi is an implementation of the xmlrpc protocol in C. It provides an easy to use API for developers to serialize RPC requests to and from XML. It does *not* include a transport layer, such as HTTP. The API is primarily based upon proprietary code written for internal usage at Epinions.com, and was later modified to incorporate concepts from the xmlrpc protocol. It passed the xmlrpc validation test suite in December 2000. As of Sept. 27, 2001, experimental support for SOAP v 1.1 has been added to the library. This support is implemented transparently to the application such that a single API can be used for manipulation of values, yet both SOAP and XML-RPC can be read or written. Various iterations of this code have been/are running at Epinions.com and are sufficiently fast for the high traffic volume this site encounters, with several xmlrpc type requests generated for each user http request. No specific speed claims are made. Your mileage may vary.

The Zillion Project is a distributed computing project reminiscent of the good old Zilla.app of NeXTstep days. It is based on GNUstep, the most promising OPENSTEP replacement as of today. Jobs can be created from simple template projects and can be submitted with a single command to the Zillion Server which in turn will distribute the job amongst the registered clients. No other network resources than the distributed objects (DO) port of the server machine has to be available. The key features are as follows: * Rapid turn around cycles for job submission * Dynamic addition/removal of client nodes * Full OO-design * No need for shared network resources * Real-time capabilities * Lean and clean * Open and free LICENSE: BSD

- Much from HTML 4.0 - that is relevant for printing - is supported (incidentally, the PostScript and PDF versions of the HTML 4.0 draft, were generated using html2ps). For example, all character entities (except &zwnj;, &zwj;, &lrm;, and &rlm;) are supported. - Many possibilities to control the appearance. Starting with this version, this is mostly done using configuration files. - Support for processing multiple documents, also automatically by recursively following links. - A table of contents can be generated, either from the links in a document, or automatically from document headings. - Configurable page headers/footers, that for example can contain document title, URL, page number, current heading, and date. - When converting the PostScript document to PDF - using some other program such as version 5.0 or later of Aladdin Ghostscript, or Adobe Acrobat Distiller - the original hyperlinks in the HTML documents will be retained in the PDF document. - Automatic hyphenation and text justification can be selected.