Granted there are situations that seem to require an "always up" connection, but really the only one that I can think of that really requires one is Telnet, because it's simply a window waiting for user input, and you can't assume anything about how the user is going to work. I tend to leave myself connected to my unix workstations for weeks at a time.
Almost everything else is some form of 'batch' processing. Wait for data to come in, send it out. Most of the time, the waiting for data part is generally MUCH longer than the sending part. Why hold open the connection forever if you're rarely sending data (on average). Opening and closing TCP connections is a relatively fast operation. If you are having to rely on something to keep the connection alive, then you're describing a situation where you should be opening and closing the connection as needed. At least most of the time that's going to be true.
So, I don't know what you're writing, it may be that "always up" is really a requirement, I'm just asking that you think hard about this question, because I'll contend that it's actually easier, once it's written, to support & maintain a program that opens and closes the connections as needed than it is for one that tries to keep the connection alive.
The reason is that you'll already have the error handling routines well tested to insure that the connection is opened and closed correctly before trying to send the data. If the connection is assumed to always be there, the error handling routines will be viewed more as being in the way, and will likely not be very robust, rather than as an important and integral part of the program.
While I've never had the need to program this type of thing, I do program quite a lot, so understand that while doing it the right way is seen as a pain right now, the reward is worth the more difficult path.
-Scott | [reply] |