On 5/18/06, Carl <[EMAIL PROTECTED]> wrote:
With UDP the IP/UDP header is 40 bytes and any size payload is allowed up to 8k. That is you can send one byte of data (total packet length 41) to 8192 bytes of data (total packet length 8232).
Reminds me of my time with GE building RTU's.
I think that its the only logical approach given the characteristics of the network.
On Thu, 2006-05-18 at 07:48 -0600, Robert Lewko wrote:
> 3 seconds right there. Using UDP you can actually get 2 2k packets
> through with their ack returned in 6 seconds. BTW I have restricted
> myself to a 2k packet size in my program.
Maybe sometimes the connection is so bad that it is hard to get even a
2k packet through. What is the minimum packet size that you can use with
UDP?
With UDP the IP/UDP header is 40 bytes and any size payload is allowed up to 8k. That is you can send one byte of data (total packet length 41) to 8192 bytes of data (total packet length 8232).
> This whole discussion is based on that when I get a broken connection
> when the client sends some data that there is no way to tell the
> socket that it can try again. If someone knows how to do that and can
> point me to docs then I will be glad of the info. In my reading of
> Stevens I didn't see how to recover from a broken connection.
>
I have used a protocol, http://dnp.org that uses application layer keep
alives to determine if the TCP connection is bad. For example if the
timeout is set to 20 seconds: if the ack to the keep alive is not
received within 20s then it will close the TCP socket and attempt to
reopen another one.
Reminds me of my time with GE building RTU's.
> The UDP server can be MUCH simpler by handling each packet as a self
> contained entity. It gets a packet from the client, processes that
It sounds like UDP is a good approach in your case. TCP would be too
much overhead.
I think that its the only logical approach given the characteristics of the network.
I'm curious as to what the troubleshooting tools that Gustin has
suggested will produce.
Carl
_______________________________________________
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
