See: Description
Interface | Description |
---|---|
TcpAgentListener |
Declarations of event notification methods of the TcpAgent class.
|
TcpBridgeListener |
Declarations of event notification methods of the TcpBridge class.
|
TcpNodeListener |
Declarations of event notification methods of the TcpNode class.
|
Class | Description |
---|---|
PackageInfo |
Class to provide the current package version.
|
TcpAgent |
Several agents may be running on the same host using the same port,
because they behave like HTTP clients connected to the relay server.
|
TcpAgentAdapter |
Empty implementations of the TcpAgentListener interface.
|
TcpBridge |
A bridge acts as a TcpNode, thus seen from the network it is a HTTP client
connected to the TcpRelay server.
|
TcpBridgeAdapter |
Empty implementations of the TcpBridgeListener interface.
|
TcpNode |
TcpNode instances are interlinked via the TCP/IP protocol through a TcpRelay.
|
TcpNodeAdapter |
Empty implementations of the TcpNodeListener interface.
|
TcpProperties |
Class to read library options from a property file that
may be modified as needed.
|
TcpTools |
Declaration of some useful static helper methods.
|
Enum | Description |
---|---|
TcpNodeState |
Enumeration of connection states.
|
Aim:
Computer nodes interlinked by TCP/IP running behind a firewall (see Description for more information).
The most common way to interlink computers via the Internet is using the TCP/IP protocol. Java's core API is well-designed for developing standard socket-based client-server applications and an extra library layer for TCP/IP communication seems to be an overkill. The situation becomes more complicated if the hosts are protected by firewalls. In a typical situation (computers in a university PC pool, inside an enterprise building, etc.) the clients are restricted to outgoing HTTP connections via IP port 80. The TcpJLib library allows you to interlink hosts from a firewall-protected sites and develop typical stream-based multitclient-server applications using a HTTP tunneling technique: A server using port 80 possibly located behind a firewall acts as a relay between nodes somewhere else, possibly also behind firewalls. Seen from the network, the relay server acts as a standard HTTP server and the nodes connects as standard HTTP clients.
In this scenario another problem must been solved. The HTTP protocol is stateless. Normally a client performs a HTTP GET request to the server that opens a socket connection. The server replays sending some data and the socket is closed. With TcpJLib the relay server and the nodes are connected by a continuously opened up- and downstream as long as you like. This is realized by feinting the network as if a long WAV file were up- and downloaded. Keep-alive data is transferred at an interval of about 1 second completely transparent to the user. Moreover this trick allows the relay and the nodes to detect if one of the partner is shutdown.
Despite, seen from the network, a TcpJLib node is a HTTP client, logically it may act as a server as well as a client. We call the node a bridge when it acts as a server and call it an agent when it acts as a client. Thus with a bridge and any number of agents you may develop a multiclient-server topology completely free of firewall constraints.
The relay server is part of the TcpJLib distribution. It is session-oriented, e.g. many bridge/clients-applications may use its service in parallel by specifying a unique session ID. The relay IP must be known to all participants, so it should run with a fixed IP address or with a fixed IP alias that is DNS mapped to the current IP address. When you use the TcpJLib library in default mode, you are automatically linked through our relay server located in Bern, Switzerland.