Re: flush buffer using socket recv() with non-blocking flag

Hello,

On 1/28/2011 8:38 AM, hockchai Lim wrote:

Sometime if the CISCO route is not configured correctly, I'll see the
respond being echo back to me (seeing the same respond twice).

Ohhhhh... I see what you're saying, now... Normally, in TCP, it's not
possible to get the same response "accidentally" sent twice. In a normal
TCP application, the TCP protocol itself guarantees that this cannot
happen... therefore, there's no reason to read again after you've received
a (complete) response.

But you have something else in the mix... some CISCO modem appliance that
can potentially cause messages to duplicate. (That's a situation I've
never had in TCP)

So you want to read the socket in non-blocking mode to clear any
duplicated messages from the buffer. That makes sense... But, how will
you know when you've gotten them all?

Seems to me you run the chance of calling recv() in non-blocking mode, and
then getting nothing, meanwhile, duplicate data is still intransit on the
network. This isn't a healthy scenario!

I guess the best you can do is call recv() with select() in a loop, until
you get no data for a certain time period (maybe wait 1 second, and assume
that any duplicate data would've arrived in that second.) And yes, a
non-blocking socket would be best for that. (Frankly, I use non-blocking
for all of my sockets, these days. Apps that use blocking never seem to
be robust enough for me.)

You could do this with blocking as well, and use the alarm() API to give
you a timeout on the socket. Non-blocking is better, IMHO, but it's also
more complicated.

So, I'm kind of worry that this echoing problem might throw my app to
become
out of sync on this one to one send and recv relationship.

For sure.

Unfortunately, you can't eliminate that chance completely. The extra
recv() might solve the problem *most* of the time, but it's possible for
network lags or packet loss to cause TCP data to be delayed for as long as
2 minutes, so it's possible your duplicated data might not appear until 2
minutes have expired. (And I'm sure you don't want to add a delay THAT
long into your application!)

But, yes, calling recv() in non-blocking mode will probably help a lot.
Frankly, though, the best solution is to eliminate the problem that causes
data to be duplicated.