> Other solutions are obviously possible, including using server 
> socket only at master side.

My application only used a server at the master side, albeit three for
redundnacy, so the clients only contacted the servers to report status
and pick-up waiting commands.  Actually, this was partially true, there
was an emergency server in the client PCs in case something went wrong. 

But there were also UDP broadcasts from the servers every 30 seconds, if
they wanted the clients to call home more urgently.  These packets also
served to confirm that networking was all OK for the clients. 

Some of this depends on the session duration strategy, whether clients
contact the servers say once a minute or every five minutes or something,
or if they leave the connection open continually.  

Short sessions are better for resources, fewer connections, but is
horrible for SSL due to the massive overhead establishing a session and
checking certificates.  This is probably why Arno suggested not using SSL
but just data packet encryption.  

Permanent sessions solve the connection overhead and allow easy commands
from the server, but may cause resource problems on the servers, routers
and firewalls, and there are stale session issues if the client
disappears unexpectedly such as with wireless LANs where you need
timeouts and keep alive packets.  

As we have all said repeatedly, SSL is a minor issue compared to other
design concepts and should be left until a lot of other issues are

Also, sending file using a private protocol is simply re-inventing FTP
and will add substantially to project cost and timetable.  It may be OK
for the odd short file, but anything more complicated should use FTP.  My
project was the reason I spent a lot of time in the few years improving
FTP and adding many new FTP commands.   


To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to