> A question was asked to me recently on the strategy on which 
> method to use
> on using sockets , perhaps the discussion list could point 
> out which is the
> best method to use. We are looking to develop a system which 
> using sockets
> will communication with a server system. It will link into an 
> existing Cobol
> system. From the limited exposure I have been pointed into 
> the direction of
> using some sort of threading to ensure that no bottle necks 
> are created. The
> system we are developing will only have 60 users so it is not 
> vast. Can we
> get away with using the single socket and no threading option 
> or should we
> always go for multi threading in some way using IPC or other 
> such methods.

Whether or not a single socket/thread will carry the load is not a
function of how many users are involved, but rather of how much traffic
the link must carry. If you have a thousand users, each exchanging a
20-byte packet with the server once an hour (with some reasonable
distribution over the hour), a single server connection is plenty. If
you have 3 users with continuous, large-scale data exchanges, you'll
probably experience problems unless the server is capable of multiple
simultaneous operations (which doesn't necessarily imply multiple
threads).

You say "using the single socket" for multiple users, which implies UDP.
The first thing to establish is that your application is suitable for
UPD; i.e. it doesn't mind if packets are occasionally lost, or arrive
out of sequence or duplicated. If that isn't the case, and you need TCP,
then "single socket" is no longer in the picture: each client will
require a connection to a separate server-side socket. At that point the
question becomes "do you need multiple threads to operate the multiple
sockets?" The answer to that goes back to the original question: how
much data gets moved how often? If you know the answer to that, we can
make intelligent recommendations as to the server architecture.

Steve

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *