This application has taken some time to develop and last friday when i was on his site, actually his truck where the application runs, the application was able to recover from lack of satellite signal.  The typical period where the satellite is out of range is about 10 minutes.

What is happening this afternoon is that the signal meter on the modem is showing strong signal and there is no data getting back.  Like I said before the packets are getting to the server but not being returned to the client.

Usually when I lose packets there may be one or two per minute, but the client side of this application is designed that the client is in control of the communication and it will retransmit until it receives the ack from the server.  Actually I got the design from Stevens "Unix Network Programming" the chapter that discusses advanced UDP.

So to sum up I think that something upstream is blocking the packets on the return trip.  Again this is the first time that I have seen the network act like this for an extended period of time.  My guess is that some admin set something somewhere so that these packets are getting lost. I just don't know what to do in this case.

I repeat.  My code is working when the packets get through.

On 5/17/06, Aaron J. Seigo <[EMAIL PROTECTED]> wrote:
On Wednesday 17 May 2006 19:02, Robert Lewko wrote:
> I am using UDP because the client is using a satellite modem.  The server
> uses UDP port 9608.  When the server gets a packet it just gets the source
> address and returns the response packet to the sender.  Like I said I have
> had no problem with that port both while I have been developing the code
> and for the last week until this afternoon.

as you know, udp has no guarantee of delivery (or ordering for that matter).
so if there are any network issues whatsoever you can lose udp packets pretty
easily; tcp packets will resend when they aren't ack'd. if you need
guarantees with udp you usually end up setting up some sort of ack-on-failure
(as opposed to tcp's ack on success which suppresses a resend). welcome to
udp =)

--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com )


_______________________________________________
clug-talk mailing list
[email protected]
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying



_______________________________________________
clug-talk mailing list
[email protected]
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying

Reply via email to