[erlang-questions] Sending a tcp packet containing null data

Valentin Micic v@REDACTED
Mon Jun 27 16:12:02 CEST 2011


Hi

I'd like to implement a generic link-test facility for TCP connections -- something that would work similarly to TCP keep-alive; however, under complete control of the calling ERLANG process with respect to sending and receiving of control packets.
By the same token, I'd like this test to be transparent (as in: non-intrusive) to the peer application. In other words, I would *not* like such an empty (null data) packet to be propagated to the remote peer application, but expect the remote TCP stack to issue an equally empty "ACK" packet (or stream of data, if available), which would be propagated back to the caller. 

Thus,  I have a number of problems on multiple levels, but first and foremost, I have no idea how to achieve this (other than hoping that TCP keep-alive would be supported on a particular machine) :-)

So, how can I force a null data packet to leave the local machine. Did try gen_tcp:send(Socket, <<>>), however, this didn't work (well... why should it?)

Maybe the whole problem can be reduced to the above -- if the remote TCP stack receives such a packet, it will be obliged to send an ACK, failing which the local TCP driver would eventually tear-down the connection, therefore informing the local ERLANG process about such an action, right? (as it would in a case of TCP keep-alive)

Another valid question can be: Is it worth-while going to a trouble of trying to do this?

My current feeling is -- Yes; largely because I had (did I say had? I meant still have) to do application-level link testing with almost every project that requires some form of connection pool management.
Why is this important? Well, not much if you prefer to ignore the golden rule about customer always being right (and we all know they can be quite left from time to time); unfortunately, if one is to observe important (evolution related) rules, one would need to consider easier ways to do this -- that is, provide for a link-testing even if the remote peer application does not support a link testing primitive.

Kind regards,

V/


More information about the erlang-questions mailing list