How can a server accept data from multiple clients simultaneously using SSL connection ?

[Rahul Dayal Sharma]

Hi,

I'm new to programming and am currently venturing socket programming using Java I noticed an exception taking place when I tried to implement a basic connection using SSL. The event I noticed is as follows :

I have a server which is able to intake request from a client such that the client is able to transmit its data (a video file) over to the server side in the form of a stream of bytes using an SSL connection. I noticed that when I try to transmit data to this server using more than one client (basically multiple clients but I took 2 for test purposes), the stream is getting messed up as the data is incoming from both clients through the same (DataInputStream in = new DataInputStream; in.read();) stream thus throwing an exception and also corrupting the data thus rendering the files useless. How can I ensure that the data flow does not get affected while making sure that the client is able to accept connections for data transfer from multiple clients ?

[Tim Holloway]

The server itself is responsible for keeping track of things.

For example, consider one of the most popular types of servers - the web application server.

HTTP is a stateless protocol. That is, instead of connecting for a long-term session, every request is a short-term connection ended by a disconnect until (if!) the client sends another request. Each HTTP request has a standard format. It has a URL, which tells where imside the server the request should be routed. It has a "reply port" assigned at the client side when the incoming port listener accepts the connection and it uses the reply port (which is randomly chosen) to respond to the client with the web response.

In between times, a server such as Tomcat maintains a pool of identical, but idle threads. When a request comes in, Tomcat parses it, pulls a thread out of the pool and runs the process-handling (application) code under that thread. The output is sent out via the reply port as a data stream and Tomcat closes the data stream when the end of data has been reached. So, although multiple clients are coming in, each one can be uniquely defined by its return IP/port address.

That takes care of the coarse-grained differentation. All requests coming into a single webapp look the same, however, which is we we piggyback session information to the request data if we want to operate statefully. Generally either a cookie or an appendage to the incoming URL identifies which session (user) is being handled by that particular request thread. So that all the users of a particular webapp don't get all jumbled together.

As far as SSL goes, there's also the question of negotiation of the encryption tokens and protocols. Ideally, you don't want to re-negotiate on each request, but I've never looked into details. It Just Works. I can tell you that in order to cut some of the overhead on establishing connections, even unencrypted requests are often managed by a connection "keep-alive" mechanism, but I'm not sure how much of the basic keep-alive handles SSL and how much (if any) is managed by some other mechanism.

A good place to find out is to look through the "RFC" documentation. RFCs are the official documents defining the Internet's protocols.

[Rahul Dayal Sharma]

Hi,

I believe what you explained just now is correct when you consider it in terms of an already built server (commercial one, so to say), which manages the requests coming in from the client and differentiates them using a single thread for each incoming request. But my question is, if I wish to implement a simple TCPServer.java program over a connection (I've managed to use SSL employing a self signed certificate for verification), how may I manage multiple clients sending their data (video files) simultaneously in the form of byte streams using the same DatainputStream (at the server end) ? because my implementation works well for a single client, now I'm looking to implementing it for multiple clients... Any ideas on this ?

[Tim Holloway]

The same way they did it.

Operating a server program is more than just opening up a connection. You have to set up a connection listener and wait on the listener. When the listener gets an incoming connection request, you hand off the new connection for processing, which you can do either by spawning a new thread for each connection, obtaining a connection-handling thread from a pool of ready-made threads you've set up, or by simply running asynchronous I/O so that your server can switch off between them as each connection goes into a wait.

The connections themselves, like I said, are all unique. A TCP/IP connection contains 4 specific items of information in each packet that identify the connection: The destination IP address and port and the source IP address and (reply) port. Even if the same machine makes 2 simultaneous connections, examination of network traffic will be able to tell what data goes with what connection because they will have been assigned different reply ports by the client when the client opened the connection.

This is true whether you're doing "one-shot" connections like HTTP request/response connections or continuous sessions where the connection is held open indefinitely. The response address/port remains constant for the duration of the connection no matter how many or few the transmitted packets are or in which direction.