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.
midrange.com
