in reply to maintain tcp socket

I'm a network engineer, meaning I build and support the infrastructure of my place of employment. I've not done this type of programming, but...

I implore you, don't take the easy or cheap way out. Do the networking stuff, properly! I've had to defend our network many, many, many times against programers who've not bothered to write the socket handling software correctly, then thought it was "the network's fault".

Tip 1: No, it's not ok to assume that you can create a connection and leave it up forever. We have to maintain the network, and failures can and do happen. You need to open the connection when you have traffic to send, and close it when you're done, then open it again when you have the next batch of stuff to send.

Tip 2: It's also not ok to assume that you'll never have to deal with a network failure. Most of the time the failure will be a failure to open the connection, but occasionally it will happen that you'll have to deal with the failure of an already open connection. Deal with those failures properly.

Tip 3: CPAN is your friend. There are lots of very smart people who've been down this road before, I'm sure there are modules on CPAN to make most of this pretty painless. Posting this question was also a good thing, I'm sure you'll find good examples of code from other monks who have experience doing this stuff.

I will thank you in advance for your Network Support group for your future attention to these details.

-Scott

Replies are listed 'Best First'.
Re^2: maintain tcp socket
by Anonymous Monk on Apr 12, 2005 at 16:00 UTC
    Hi,

    thanks for response.

    I agree, but maintaining TCP connection always up is a requirement in my situation - connected TCP socket is a sign of my client being alive.

    I've searched CPAN all the way but got no single explanation to socket options I described. There are some packages that deal with TCP sockets, but no one has functionality to keep TCP connection alive in this manner (I could be wrong in this one...) ...

    So perl monks are my last hope to find some solution to this. I've searched Internet and found only C library references (almost no Perl sources) that I don't know how to use under Perl...

    From other functionality I just want to resend data if something failed and that's it...


    Thanks in advance for Perl wisdom,
    regards,
    Rob.
[reply]
      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]

In Section Seekers of Perl Wisdom