Re: recv WSAENOBUFS error



Thanks for the replies. I wasn't specific in my original post about
the sending side. The send end of the transaction does break the
transfer up into 8K chunks. The receive side does properly handle
partial transfers, so it basically works. I think the problem is that
it always asks for the "packet length" amount in the call to recv.
When I instrumented the code, it turns out that it still takes many
recv's to actually receive the whole buffer.

As for the zero-buffering technique, I actually tried this, as an
alternative, but it didn't seem to fix my problem. The parameter I set
to 0 in setsockopt was SO_RCVBUF. Is this the proper one? Would you
expect an advantage to the zero-buffering method in terms of
performance?

Thanks again,
Mason

On Dec 19, 2:43 am, "Arkady Frenkel" <arka...@xxxxxxxxxxxxxxxx> wrote:
Additionally.
You can set kernel-mode buffer with setsockopt but you'll quickly finish
your non-page ( kernel ) memory if you'll start to do it. For large buffers
you can use zero-buffering ( set size of kernel socket buffer to 0 with
setsockopt ). In this case winsock will use your user-mode buffer which can
be very big.
Arkady
P.S. BTW default kernel-mode buffer size for socket is 16K ( from W2K )

<i...@xxxxxxxxxxx> wrote in messagenews:1166504011.731450.124570@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Hi,

If I understood you correctly, you are trying to send large data chunks
in one command or atleast with big pieces of data (more then 1.5kper
call)

Internet packets are 1.5k long, so it's advised to send data over TCP
using 1.3k-1.5k (I advise 1.3k) data length, and to send the excpected
data size (like 64mb in your example) before sending the actual data,
the reason is that TCP is stream oriented and not packet oriented
(unlike UDP which is what you send is what you get), so the other side
will not receive the data in the same exact way you sent it, what I
mean is that recv won't have to look exactly like your send, you can
send 1.5k then 1.5k and the user will get 2k then 1k.

When sending data bigger then 1.5k it will cause the packet to fragment
using IP fragmentation option and will cause delays in send/recv and
every packet loss/retransmission will cost you in greater bandwidth and
loss of performance.

Good luck,
Barak Weichselbaum,
http://www.komodia.com

boarding_ga...@xxxxxxxxxxx wrote:
Hi,

I don't have a lot of experience with sockets, but I'm debugging a
problem in some existing software, and could use some help.

I have a couple of processes talking through a non-blocking socket.
In general, everything works fine, until a particularly large data
transfer (~64 MB) is attempted. When the receiving side tries to do a
recv, a WSAENOBUFS error is returned. I've been searching around a
lot, and have found a workaround to this problem, but I want to make
sure it's an appropriate fix, and would like to understand exactly why
it fixes the problem, and what impact it might have on performance.

The original code determines the length of the data (contained in the

first several bytes of the data), then allocates the appropriate space
for the data, and calls recv with the full length as the "len"
parameter. This recv call fails when that large data length is
encounterd. Based on information I found during my research, I changed

this code to send 64K as the maximum length to recv, and I loop and
piece together the results until all of the data is received. This
seems to "fix" my problem. However, I've also seen suggestions about
changing the receive buffer size using setsockopt, changing various
registry settings, etc (none of which have seemed to help me). What I
would like to understand is what the various buffers involved in the
socket transfer are, and how they can be configured. It seems like the

parameter I'm changing has some effect on some sort of memory
allocation somewhere, but I'm not sure what it's actually changing.
Also, I have concerns about performance impact. It seems like when I
pass large amounts of data (< 64MB, so it succeeds), multiple recv
calls are required to get all of the data anyway, so I'm hoping that
this change won't really affect the performance too much.

Any advice or clarification would be greatly appreciated!

Thanks for your time,
Mason- Hide quoted text -- Show quoted text -

.

Relevant Pages

  • Re: recv WSAENOBUFS error
    ... it always asks for the "packet length" amount in the call to recv. ... You can set kernel-mode buffer with setsockopt but you'll quickly finish ... your non-page (kernel) memory if you'll start to do it. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: recv WSAENOBUFS error
    ... it always asks for the "packet length" amount in the call to recv. ... You can set kernel-mode buffer with setsockopt but you'll quickly finish ... your non-page (kernel) memory if you'll start to do it. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: recv WSAENOBUFS error
    ... cross-posting, I did cross-post it initially, but I just started using ... it always asks for the "packet length" amount in the call to recv. ... You can set kernel-mode buffer with setsockopt but you'll quickly finish ...
    (microsoft.public.win32.programmer.kernel)
  • Re: recv WSAENOBUFS error
    ... ethernet NIC driver send to/from line. ... it always asks for the "packet length" amount in the call to recv. ... You can set kernel-mode buffer with setsockopt but you'll quickly finish ...
    (microsoft.public.win32.programmer.networks)
  • Re: Merging relayfs?
    ... > kernel to implement speculative tracing, ... relayfs was prepared for low latency on move data outside kernel space, ... getting data from probes do not require organize all them in regular ... Only in all cases where buffer must be neccessarly moved outside kernel ...
    (Linux-Kernel)