Free communicating software for linux

SAP R/3 Communications Suite allows SAP R/3 servers to communicate with external devices such as fax and GSM modems by sending and receiving a fax or SMS.

SAP R/3 Communications Suite provides an easy configuration through a Web interface and a JMX console.

Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.
Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc).
Main features:
- Unison runs on both Windows and many flavors of Unix (Solaris, Linux, OS X, etc.) systems. Moreover, Unison works across platforms, allowing you to synchronize a Windows laptop with a Unix server, for example.
- Unlike simple mirroring or backup utilities, Unison can deal with updates to both replicas of a distributed directory structure. Updates that do not conflict are propagated automatically. Conflicting updates are detected and displayed.
- Unlike a distributed filesystem, Unison is a user-level program: there is no need to modify the kernel or to have superuser privileges on either host.
- Unison works between any pair of machines connected to the internet, communicating over either a direct socket link or tunneling over an encrypted ssh connection. It is careful with network bandwidth, and runs well over slow links such as PPP connections. Transfers of small updates to large files are optimized using a compression protocol similar to rsync.
- Unison is resilient to failure. It is careful to leave the replicas and its own private structures in a sensible state at all times, even in case of abnormal termination or communication failures.
- Unison has a clear and precise specification.
- Unison is free; full source code is available under the GNU Public License.

SipUnit provides a test environment geared toward unit testing SIP applications. SipUnit project extends the JUnit test framework to incorporate SIP-specific assertions, and it provides a high-level API for performing the SIP operations needed to interact with or invoke a test target.
A test program using the SipUnit API is written in Java and acts as a network element that sends/receives SIP requests and responses. The SipUnit API includes SIP User Agent Client (UAC), User Agent Server (UAS), and basic UAC/UAS Core functionality - the set of processing functions that resides above the SIP transaction and transport layers - for the purpose of interacting with the test target.
SipUnit uses the JAIN-SIP reference implementation as its underlying SIP stack/engine. The primary goal of SipUnit is to abstract the details of SIP messaging/call handling and facilitate free-flowing, sequential test code so that a test target can be exercised quickly and painlessly.
A test program using SipUnit API:
1. Extends SipTestCase
2. Creates SipUnit API objects - SipStack, SipPhone, SipCall, etc.
3. Calls methods on the object(s) to set up and initiate action toward a SIP test target. For example: SipPhone.makeCall("sip:roger@nist.gov", SipResponse.OK, ....) makes a vanilla call to sip:roger@nist.gov and blocks until an OK is received or a timeout occurs. The test target could be any node up to and including the final destination of the INVITE request message.
4. Verifies the results of the action involving the test target using both the SIP-specific assert methods provided by SipUnit and the standard JUnit assert methods. For example: assertHeaderContains(sipCall.getLastReceivedResponse(), "From", "sip:amit@nist.gov"), assertEquals("Unexpected response received", SipResponse.OK, sipCall.getReturnCode()).
Main features:
- A basic set of SIP-specific assert methods - assertHeaderPresent(), assertHeaderContains(), assertBodyPresent(), etc.
- High level API for interacting with a test target.
- Low-level SIP messaging access for interacting with a test target.
- Registration/unregistration and call processing with or without authentication (DIGEST).
- Support for testcase-specified timeouts.
- Support for different routing configurations.
Enhancements:
- Support was added to the SipPhone and SipSession classes for running SipUnit tests from behind a NAT and communicating with a SIP server on the Internet.
- A STUN example test was included.
- An enhancement that allows more flexible multiple SIP stack creation was incorporated.

QuickFIX is a full-featured open source FIX engine, currently compatible with the FIX 4.0-4.4 spec.
QuickFIX/J runs on Windows, Solaris, Linux, FreeBSD and Mac OS X. APIs are available for C++, Java, .NET, and Python.
The Financial Information eXchange (FIX) Protocol is a "language" which defines specific kinds of electronic messages for communicating securities transactions between two parties.
FIX defines only the format of the messages and the session-level interaction between two applications.
Enhancements:
- This announcement covers both the 1.0.0 release and 1.0.1 maintenance release.
- Features include updated compatibility with QuickFIX C++/JNI, an update to MINA 0.9.x for networking, support for variables in configuration files, performance optimizations in the file message storage plugin, and new file-based message logging options.
- It also includes several bugfixes.

Anca is a H.323 client for Qt 3.x. It means that it allows communicating (voice/video) with other similar clients over internet, eg. with Gnomemeeting, OhPhone, NetMeeting etc.
Its design is minimalist and clean; has a support for embedded devices. It is very modular.
Main features:
Core:
- Audio/video communication via H.323 v. X
- Embedded devices support (framebuffer support, efficient design etc.)
- Call diversions - server-side forwarding
- Plugin system
Plugins:
- Addressbook with LDAP support
- DTML tones
- OSS sound
- V4L video
- Video preview
Enhancements:
- Sound and VideoIn plugins were changed to be compiled with the latest PWLib and OpenH323 FIXED: Video grabber failure resulted in crash

Volity::Seat is a Volity seat, containing some players.

SYNOPSIS

# From within a Volity::Game subclasss code:
my @seats = $self->seats;

# Or, given a Volity::Player object:
my $seat = $player->seat;

# Now tell the seat they just picked up the Three of Clubs:
$seat->call_ui_function("draw_card", "3C")

An objects of this class represents a seat at a Volity table. Volity players who are actually playing a game sit in seats, and referees address game-specific RPC calls to seats, not to individual players. See the main Volity documentation for more information about the seat concept: http://www.volity.org/wiki/index.cgi?action=browse&id=Seats

USAGE

As a game programmer, you need never create, modify, or destroy these objects yourself; that is all handled for you by the other objects that make up a Frivolity-run table, particularly the referee (see Volity::Referee). However, several methods of Volity::Game, the module you subclass to create your own Perl-based Volity game, will return objects of this class. Several crucial functions of communicating with a games players involve calling methods on these objects, including the all-important call_ui_function method (described below).

Your Volity::Game subclass must define some variables that assist the referee in seat creation, particularly the seat_ids and required_seat_ids class variables. If you wish to extend this class for your game, you can speficy a Volity::Seat subclass to use through Volity::Games seat_class method. All these are described in detail within Volity::Game.

Custom Eclipse Builder is a lightweight Ant-based project to build a company and personal customized Eclipse distribution including company and personal relevant plugins, preferences and settings.
The modern software development process becomes more and more distributed characted. Now, a usual project is not a one-men work more, but a collective work of bunch of people communicating through network. Therefore, its very important that each involved developer stands to the rules and guidelines applied for the project.
There are many tools that makes the development process easy. One of these tools that increases in popularity more and more is Eclipse. The number of companies, organizations or project teams using Eclipse grows permanently. Typically, in such a company a developer takes itself care of downloading and configuring Eclipse and all kinds of Plugins.
Therefore, the more developers using Eclipse within of organization the more different versions, configurations and settings do exist. When a group of developers is working for a project and sharing the projects resources (and this is the typical case) using of different tools and versions may lead to any kinds of conflicts (unfortunately this is the typical case too).
The Custom Eclipse Builder is a very easy way to solve all these problems. After you have installed and configured Builder you can build your own Eclipse distribution each time you wish (e.g. by scheduling a cron job) in just a few minutes. The Builder will download all desired Eclipse- and plugins distributions full automatically.
There is no need to check a new plugins version you wish to include in the distribution is realised. The Custom Eclipse Builder takes care of plugins version management. Once installed and configured you can use Builder over a couple of months without any modifications.
Enhancements:
- This release fixes some minor bugs and supports building distributions based on Eclipse 3.2M1, 3.2M2, and 3.2M3.

Check Your Network Address Translator for Compatibility with Peer-to-Peer Protocols.
If you are accessing the Internet from behind a Network Address Translator (NAT) of some kind, I would appreciate your help in surveying the behavior of different NATs, in terms of how and whether they support a certain technique for enabling peer-to-peer communication between NATted hosts (particularly when both endpoints are behind NATs). Down, you can understand what NAT is.
Suppose there are three communicating hosts: A, B, and C. Host A is a "well-known" Internet server with a permanent IP address, which acts as an "introducer" for the other two nodes. (For example, Host A might be a well-known ultrapeer or a game catalog server of some kind.) Host B, using Host As "introduction" services, would like to establish a direct peer-to-peer connection with host C. Both B and C, however, are behind (probably different) network address/port translators, and neither of them has exclusive use of any public IP address.
To initiate a peer-to-peer connection with host C, host B first sends A a message requesting an "introduction" to host C. A sends B a reply message containing Cs IP address and UDP port number as reported by host C, in addition to Cs IP address and UDP port number as observed by A. (If C is behind a NAT, then these two address/port combinations will be different.) At the same time, host A sends host C a message containing Bs IP address and UDP port numbers - again, both the ones reported by B and the ones observed by A, which will be different if B is behind a NAT.
Now B and C each know that they want to initiate a connection with each other, and they know each others public (NATted) as well as original IP addresses and UDP port numbers. Both B and C now start attempting to send UDP messages directly to each other, at each of the available addresses. If B and C happen to be behind the same NAT, then they will be able to communicate with each other directly using their "originally reported" IP addresses and UDP port numbers.
In the more common case where B and C are behind different NATs, the "originally reported" addresses will be useless because they will both be private IP addresses in different addressing domains. Instead, the IP address/UDP port combinations observed by A can be used in this case to establish direct communication. Although Bs NAT will initially filter out any UDP packets arriving from Cs public (NATted) UDP port directed at Bs public port, the first UDP message B sends to C will cause Bs NAT to open up a new UDP session keyed on Cs public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by Cs NAT, but will be able to start passing through the firewall as soon as Cs first message to B causes Cs NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with As help) simultaneously in each direction.
Required NAT Behavior
There is one important requirement that the NATs must satisfy in order for this technique to work: the NATs must be designed so that they assign only one (public IP address, public UDP port) pair to each (internal IP address, internal UDP port) combination, rather than allocating and assigning a new public UDP port for each new UDP session. Recall that a "session" in Internet terminology is defined by the IP addresses and port numbers of both communicating endpoints, so host Bs communication with host A is considered to be one session while host Bs communication with host C is a different session. If Bs NAT, for example, assigns one public UDP port for Bs communication with A, and then assigns B a different public UDP port for the new session B tries to open up with C, then the above technique for peer-to-peer communication will not work because Cs messages to B will be directed to the wrong UDP port.
RFC 3022 explicitly allows and suggests that NATs behave in the former, "desirable" fashion, by maintaining a single (public IP, public port) mapping for a given (internal IP, internal port) combination independent of the number of active sessions involving this mapping. This behavior is not only good for compatibility with UDP applications, but it also helps to conserve the NATs scarce pool of public port numbers. Maintaining a consistent public port mapping does not adversely affect security in any way, either, because incoming traffic can still be filtered on a per-session basis regardless of how addresses are translated. There in fact appears to be no good reason not to implement the desirable behavior in a NAT, except perhaps for the implementation simplicity of naively allocating a new public port for every new session. Unfortunately, RFC 3022 does not require NATs to implement the desirable behavior, which has led me to wonder just how many real NATs actually do, and hence this page.
What NAT Check Does
The program natcheck.c is basically just a program that "pings" a well-known UDP port at two different servers that are publically accessible on the Internet. Both of these servers run the program natserver.c, with the command-line arguments "1" and "2" respectively. In addition, there a third "conspiring" server runs natserver with the command-line argument "3". Whenever each of the first two servers receives a UDP request, it not only sends a reply directly to the sender of that request, but also sends a message to the third server, which in turn "bounces" the reply back to the original client. The effect is that the client will receive not only solicited "ping" replies from the server the request was directed to, but also "unsolicited" replies from the third server.
To determine if the network address translator in use is implementing the desirable behavior of maintaining a single (public IP address, public port) mapping for a given (client IP address, client port), the client program natcheck.c basically just initiates a sequence of simultaneous pings to the first two servers (in case some of the requests or replies are lost in transit) and checks that the clients address and UDP port as reported by both servers is the same. If the NAT naively allocates a new public port for each new session, then the source port as reported by the two servers will be different, and its time to upgrade your NAT.
The replies echoed from the third server are used only to check whether the NAT properly filters out unsolicited incoming traffic on a per-session basis. Since the client never sends any messages to the third server, if the NAT is properly implementing firewall functionality, the client should never see the third servers echoed replies even after opening up active communication sessions with the first two servers.
Enhancements:
- The NAT Check client no longer attempts to guess whether you have Basic NAT or Network Address/Port Translation (NAPT). It turns to be quite difficult to test for this property reliably, because many NAPTs attempt to bind a private UDP port to a public port with the same port number if that port number is available, causing NAT Check to falsely report Basic NAT. The only way to test for this property reliably would be to run NAT Check on at least two client machines simultaneously, and since this property isnt terribly important to P2P apps its just not worth the trouble.
- The NAT Check client now tests for one additional NAT feature, which I call loopback translation. If a NAT supports loopback translation, it means that a host on the private network behind the NAT can communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT. Most NATs probably do not support this feature yet, but it may become increasingly important in the future where P2P clients may be located behind a common ISP-deployed NAT as well as individual home NATs. More details on loopback translation will appear in the next version of my Internet-Draft, to be released soon.
- The NAT Check client program now has a command-line option, "-v", which turns on verbose messages during the test.