Socket Server design

[Stuart]

I need to write a socket server that accepts around 100 connections, but
this could grow to a 1000, or more in time. The data throughput will be
minimal, mostly in short random bursts, but it's important those
connections stay active.

Should I be creating a new Thread for every connection? It seems a bit
wasteful, given the small amounts of data. (as little as 30 bytes in a 2
minute burst).

Are there any limitations I should look out for?

Stuart.

 

[Gordon Beaton]

I need to write a socket server that accepts around 100 connections,
but this could grow to a 1000, or more in time. The data throughput
will be minimal, mostly in short random bursts, but it's important
those connections stay active.

Should I be creating a new Thread for every connection? It seems a
bit wasteful, given the small amounts of data. (as little as 30
bytes in a 2 minute burst).

Use java.nio.channels.Selector and you can use a single thread for all
of your connections.

Are there any limitations I should look out for?

Your OS probably limits the number of open file descriptors per
process to something much less than 1000, and maybe even less than
100.

/gordon

 

[Stuart]

Your OS probably limits the number of open file descriptors per

process to something much less than 1000, and maybe even less than
100.

ouch. Less than 100. How would say a FTP server get over this? My app
will be running on Windows or Linux.

S.

 

[John C. Bollinger]

ouch. Less than 100. How would say a FTP server get over this? My app
will be running on Windows or Linux.

Typical server software sets up one listening socket with which to
receive service requests. If it is a TCP service then a new connected
socket is created in the server for each connection (if it is a UDP
service then there needn't ever be more than one socket for it; from
here out I'll ignore that possibility). When the client disconnects or
times out, the server closes the corresponding socket. This subjects
the server to an OS-dependent maximum number of simultaneous
connections, which is one reason why denial-of-service attacks are so
easy to mount.

If you are planning an FTP server specifically then you will definitely
want to read the specs (there's an RFC covering the basics somewhere in
the 8xx or 9xx range). They cover some details of how sockets are to be
handled by both client and server.

 

[Gordon Beaton]

ouch. Less than 100. How would say a FTP server get over this? My app
will be running on Windows or Linux.

I was referring to what default limits might be.

On Linux you can use ulimit to see or change the limit. Previously
there was an upper bound of 1024, but I think the real limit today
depends only on available kernel memory (and whether Java's Selector
uses poll() or select()). On windows I have no idea.

/gordon

 

[Chris Parsons]

Should I be creating a new Thread for every connection? It seems a bit
wasteful, given the small amounts of data. (as little as 30 bytes in a 2
minute burst).

I'd use java NIO (nonblocking IO) - that way you won't need to create a
seperate thread (the treading would kill your app's performance stone
dead).

NIO has gotchas and limitations though. Check out EmberIO
(http://sourceforge.net/projects/pyrasun) - someone with NIO experience
has written a wrapper API which surmounts many of the problems. I've
tried this and it's quite well wrtten and useable - not sure about
performance yet as I haven't stress tested it enough yet.

Hope this helps
Chris