Home > Archive > Unix Programming > January 2005 > How full is a UDP socket buffer
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How full is a UDP socket buffer
|
|
| Anant Padmanath Mudambi 2005-01-23, 8:58 pm |
| Hi,
I have a program in which packets are received on a UDP socket. I would
like to recv() packets from this UDP socket only if it's buffer is close
to being full.
Is there any way to find out how much data is available to be read from a
UDP socket's buffer?
Thank you,
Anant.
| |
| Michael Fuhr 2005-01-24, 3:57 am |
| Anant Padmanath Mudambi <apm9v@mamba.cs.Virginia.EDU> writes:
> I have a program in which packets are received on a UDP socket. I would
> like to recv() packets from this UDP socket only if it's buffer is close
> to being full.
> Is there any way to find out how much data is available to be read from a
> UDP socket's buffer?
See "How Much Data Is Queued?" in _UNIX Network Programming_, Volume 1,
by W. Richard Stevens. In the 2nd edition it's Section 13.7 in the
"Advanced I/O Functions" chapter (p. 365).
On some systems you can call ioctl(sock, FIONREAD, &nbytes) to find
out how much data is in the buffer. This appears to work on FreeBSD
and Solaris, but the Linux system I tried returned only the size
of the first packet, not the total. On FreeBSD the total includes
the size of each packet's address structure (16 bytes for IPv4),
while on Solaris the total is only the amount of data.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
| |
| Alex Fraser 2005-01-24, 8:57 am |
| "Anant Padmanath Mudambi" <apm9v@mamba.cs.Virginia.EDU> wrote in message
news:Pine.GSO.4.58.0501231717440.4073@mamba.cs.Virginia.EDU...
> I have a program in which packets are received on a UDP socket. I would
> like to recv() packets from this UDP socket only if it's buffer is close
> to being full.
If you really need this behaviour, which seems totally illogical to me, it
would probably be better to read into your own buffer and work from there.
Alex
| |
| David Schwartz 2005-01-24, 4:01 pm |
|
"Anant Padmanath Mudambi" <apm9v@mamba.cs.Virginia.EDU> wrote in message
news:Pine.GSO.4.58.0501231717440.4073@mamba.cs.Virginia.EDU...
> I have a program in which packets are received on a UDP socket. I would
> like to recv() packets from this UDP socket only if it's buffer is close
> to being full.
This will cause you to drop packets. You should be trying to keep the
buffer empty.
DS
| |
| Anant Padmanath Mudambi 2005-01-24, 4:01 pm |
| Hi,
Here is the reason why I need to know how full a UDP socket's
receive buffer. I have 2 threads, T1 and T2. T1 recv()s packets from a
UDP socket and puts them in a buffer in memory (call it the application
buffer). T2 copies data from the application buffer into a file on disk.
Now I would have liked the T1 thread to not get suspended while T2 is
doing I/O, but that is not happening. T1 cannot (atleast not always) empty
the UDP receive buffer while T2 is writing to file. Sometimes this causes
the UDP buffer to overflow. Is there any way to ensure that T1 can keep
receiving packets from the UDP socket while T2 is doing I/O?
One solution I thought of was to allow T2 to start the disk write only
when we know that the UDP receive buffer has enough space to store most
of the incoming packets until T1 gets a chance to recv() from it. That's
why I thought I needed to find out how full the UDP socket buffer is.
Any suggestions?
Thank you,
Anant.
On Mon, 24 Jan 2005, David Schwartz wrote:
>
> "Anant Padmanath Mudambi" <apm9v@mamba.cs.Virginia.EDU> wrote in message
> news:Pine.GSO.4.58.0501231717440.4073@mamba.cs.Virginia.EDU...
>
>
> This will cause you to drop packets. You should be trying to keep the
> buffer empty.
>
> DS
>
>
>
| |
|
| Anant Padmanath Mudambi wrote:
> Hi,
> Here is the reason why I need to know how full a UDP socket's
> receive buffer. I have 2 threads, T1 and T2. T1 recv()s packets from a
> UDP socket and puts them in a buffer in memory (call it the application
> buffer). T2 copies data from the application buffer into a file on disk.
> Now I would have liked the T1 thread to not get suspended while T2 is
> doing I/O, but that is not happening. T1 cannot (atleast not always) empty
> the UDP receive buffer while T2 is writing to file. Sometimes this causes
> the UDP buffer to overflow. Is there any way to ensure that T1 can keep
> receiving packets from the UDP socket while T2 is doing I/O?
>
> One solution I thought of was to allow T2 to start the disk write only
> when we know that the UDP receive buffer has enough space to store most
> of the incoming packets until T1 gets a chance to recv() from it. That's
> why I thought I needed to find out how full the UDP socket buffer is.
> Any suggestions?
>
> Thank you,
> Anant.
>
You don't need threads. (especially if you are on a single processor
machine) DS is right: priority#1 is emptying the socket buffer. this
leads to the following pseudo code:
while (1) {
if (socket readable)
read it in;
else
do something useful;
/* such as: writing *one* buffer to disk */
}
This will of course fail if packets come in faster then you can possibly
process, causing your buffers to fill all available program memory.
But that is (in most cases) always better than dropping network packets.
for the socket readable condition you could use select()/poll or put the
socket into non-blocking mode (and preferably both ...)
HTH,
AvK
| |
| Sean Burke 2005-01-24, 8:57 pm |
|
moi <avk@localhost> writes:
> Anant Padmanath Mudambi wrote:
>
> You don't need threads. (especially if you are on a single processor
> machine) DS is right: priority#1 is emptying the socket buffer. this
> leads to the following pseudo code:
>
> while (1) {
> if (socket readable)
> read it in;
> else
> do something useful;
> /* such as: writing *one* buffer to disk */
> }
>
> This will of course fail if packets come in faster then you can possibly
> process, causing your buffers to fill all available program memory.
> But that is (in most cases) always better than dropping network packets.
>
> for the socket readable condition you could use select()/poll or put the
> socket into non-blocking mode (and preferably both ...)
From the OP's description, it seems possible that there is only
one memory buffer shared between T1 and T2, causing the threads
to contend for the buffer. If so, then using a queue to connect
T1 and T2 would relieve such contention, and allow bursts of UDP
data to be buffered.
-SEan
| |
| David Schwartz 2005-01-24, 8:57 pm |
|
"Anant Padmanath Mudambi" <apm9v@mamba.cs.Virginia.EDU> wrote in message
news:Pine.GSO.4.58.0501241301260.15196@mamba.cs.Virginia.EDU...
> Here is the reason why I need to know how full a UDP socket's
> receive buffer. I have 2 threads, T1 and T2. T1 recv()s packets from a
> UDP socket and puts them in a buffer in memory (call it the application
> buffer). T2 copies data from the application buffer into a file on disk.
> Now I would have liked the T1 thread to not get suspended while T2 is
> doing I/O, but that is not happening. T1 cannot (atleast not always) empty
> the UDP receive buffer while T2 is writing to file. Sometimes this causes
> the UDP buffer to overflow. Is there any way to ensure that T1 can keep
> receiving packets from the UDP socket while T2 is doing I/O?
There's something wrong with your architecure. Either you have
insufficient buffering between the two threads or T2 is holding some lock
while it's doing the I/O.
DS
| |
| Farhan 2005-01-27, 8:57 am |
| You can increase the receiving buffer size
example code:
int iBufferSize = 2048;
setsockopt(iSocketFd, SOL_SOCKET, SO_RCVBUF, (void *) &iBufferSize,
sizeof(iBufferSize))
|
|
|
|
|