UDP server socket

[Ajay]

hi!

whats the maximum number of datagrams that can queue up on a UDP server
socket? or is that system dependent?
i have some code that iteratively handles datagrams, and while testing it,
i noticed that it responds to at most 3 datagrams (i tried sending 4, 6, 8
and 10 datagrams / second)
is that a system dependent feature or can i change that (i didn't see
anything in the manual)

thanks

cheers

 

[Peter L Hansen]

whats the maximum number of datagrams that can queue up on a UDP server
socket? or is that system dependent?
i have some code that iteratively handles datagrams, and while testing it,
i noticed that it responds to at most 3 datagrams (i tried sending 4, 6, 8
and 10 datagrams / second)
is that a system dependent feature or can i change that (i didn't see
anything in the manual)

I don't believe (though I'm not an expert in UDP) that you can
"queue up" UDP packets at all. At least, there are explicitly
NO guarantees as to whether any given packet will even make it
through the network, and I doubt any system provides explicit
guarantees as to how many UDP packets can be handled if there
is a backlog. If you are looking for reliable communications,
that's what TCP is for... otherwise you have to handle missed
or duplicated packets yourself.

-Peter

 

[Ajay]

I don't believe (though I'm not an expert in UDP) that you can
"queue up" UDP packets at all. At least, there are explicitly
NO guarantees as to whether any given packet will even make it
through the network, and I doubt any system provides explicit
guarantees as to how many UDP packets can be handled if there
is a backlog. If you are looking for reliable communications,
that's what TCP is for... otherwise you have to handle missed
or duplicated packets yourself.

-Peter

i am afraid i have to stick with UDP and reliability is no issue. i used
the word queue but what i really meant was buffer and what i really want
to know is how many packets get buffered (the ones that make through).
i dont believe that when i send 10 packets, 7 get lost and 3 make it
through. Since when i send 3, i always get all 3 (well except perhaps once
or twice) but i can never get any more than 3. i want to confirm if this is
a buffering issue
in my code i do something like
while 1:
data, address = self.UDPserversocket.recvfrom(1024)
#do a lot of processing which usually takes between 4-8 seconds

my question is whether the socket buffers incoming packets, what is the
size of the buffer and is there any way of increasing it.
If not, a solution may be to carry the processing in another thread, but
thats going to increase the overhead (the app. is for a PDA).

 

[Richard Brodie]

whats the maximum number of datagrams that can queue up on a UDP server
socket? or is that system dependent?

It's system dependent; depends how much buffer space the kernel wants to
give away. Pulling numbers out of the air I would have thought that some value
between 8kB and 64kB would be typical.

getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF) and the
corresponding setsockopt call appear to be what you want, though I've never
had cause to use them.

 

[Donn Cave]

my question is whether the socket buffers incoming packets, what is the
size of the buffer and is there any way of increasing it.
If not, a solution may be to carry the processing in another thread, but
thats going to increase the overhead (the app. is for a PDA).

I assume you're testing and encountering this result on a PDA, too.
I have never worked with one myself, but I assume that a platform
with more limited resources like that will naturally make more
conservative assumptions about the necessary size of buffers and
so forth.

In a simple test on MacOS X, I find that a stopped server can
wake up and process 100 or so datagrams that had been previously
sent to it, of sort of random length between 1 and 74 bytes.
I expect it could handle a lot more than that, and the same
would be true of any PC or server class Berkeley UNIX or similar.
Of course you would think the datagrams' size would have something
to do with it.

Donn Cave, (e-mail address removed)