> 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 resolved. 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. Angus -- 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
