TCPConnections

We need two things to happen to set up a TCP connection:

• One process provides an open TCP port (SocketServer in Java). There is usually a thread running in an applications that waits for new connection attempts.
• Another process connects to this port (Socket in Java).

It is not even complicated to program this be your own. You can also use our classes which we needed to implement our test peer. Let's have a look into a code example.

(A full and working example can be found in unit test connectAliceAndBob_2 in ConnectPeers.)

Provide a TCP port

// create a peer (not even a test peer)
ASAPConnectionHandler alicePeerFS = new ASAPPeerFS(TestConstants.ALICE_ID, aliceFolder, formats);

// get port number - in tests we create a new one for each unit test.
int portNumber = TestHelper.getPortNumber();

// that listener will call its peer if a new connection was establised
StreamPairCreatedListenerImpl aliceStreamPairCreatedListener = new StreamPairCreatedListenerImpl(alice);
// see explanations below.
SocketFactory socketFactory = new SocketFactory(portNumber, aliceStreamPairCreatedListener);
// start it
Thread socketFactoryThread = new Thread(socketFactory);
socketFactoryThread.start();

SocketFactory makes the trick. It better runs in a thread. It creates a TCP server socket and waits to accept connection requests. Each new connection is notified to the StreamPairCreatedListener. In out case, aliceStreamPairCreatedListener will ask peer alice to handle the newly established connection.

Now, we have a peer that provides an open TCP port. We need a callee.

Connect to a TCP port

That' straightforward. We open a socket (on Bobside) connect to the Aliceport. This open connection is handle be peer bob.

// peer as connection handler
ASAPConnectionHandler bob = new ASAPPeerFS(TestConstants.BOB_ID, bobFolder, formats);
// create a connection 
// remote peer address comes most likely from user input
// real apps should define a well-known port
Socket socket = new Socket(addressRemotePeer, portNumber);

bob.handleConnection(socket.getInputStream(), socket.getOutputStream());

Real applications can work like that. There are specifics to deal with when it comes to protocols other than TCP. But there are open issues of even on this generic level.

Open Issues

• Applications cannot create an infinite number of connections. Even the number of TCP connections are limited in a JVM. We will hardly struggle with that limit, though. There are Bluetooth environment in which just a single connection can be maintained. That's a problem and their is a solution. ASAP peers synchronize the chunks storages during an encounter. This might take some time but is is save to say that users would describe that time as within a bkink of an eye. We can close a connection, setup an connection to another peer and re-establish the first connection later. We need means to close idle connections.

• Applications using short range protocols will quite soon face a nerving effect what we call flickering: Mobile devices move with their users. A connection breaks down whenever a device crosses the perimeter of the communication range. That's not a problem but a technical fact. A device can come in communication range quickly and would re-establish a connection. Unfortunately, this flickering even happens sometimes when devices do not even move. It is quite annoying since connection establishment consumes power on our mobile phones. We do not want to offer applications which dry out our custumers batteries faster than necessary.

• ASAP is designed to use as much protocols as possible. Devices could be connected by Bluetooth and could get a chance to establish a connection via e.g. Wifi-direct. It is not necessary from applications point of view. It is - again - a bad idea from regarding power consumption.

Our EncounterManager helps to overcome the last two issues.