socket receive

[roy]

Hi, all,

I have several problems when i develop the socket receive code, i am
using recv() to get the data with gcc on the linux platform. The
questions are:
1) do i need flush the receive buffer every time recv() runs?
2) how to avoid losing data using recv(), 'cause the buffer size is
limited(1K in my case), using a bigger buffer? Is there any better
ways?

Can anyone help me out? Thanks a lot!

Roy

[Valentin Nechayev]

>>> roy wrote:

r> I have several problems when i develop the socket receive code, i am
r> using recv() to get the data with gcc on the linux platform.

You don't get the data with gcc. You possibly compile program with gcc,
there are "two big differences" (tm) here.

r> The
r> questions are:
r> 1) do i need flush the receive buffer every time recv() runs?

You can't flush receive buffer unless you are kernel developer.

r> 2) how to avoid losing data using recv(), 'cause the buffer size is
r> limited(1K in my case), using a bigger buffer? Is there any better
r> ways?

You don't lose any data unless socket is datagram one and a datagram is
larger than 1K.


-netch-

[David Schwartz]

"roy" <roy_liao2001@yahoo.ca> wrote in message
news:5c23f6ff.0307141759.1a201b67@posting.google.c om...

> Hi, all,

> I have several problems when i develop the socket receive code, i am
> using recv() to get the data with gcc on the linux platform. The
> questions are:
> 1) do i need flush the receive buffer every time recv() runs?

Huh? What does this mean?

> 2) how to avoid losing data using recv(), 'cause the buffer size is
> limited(1K in my case), using a bigger buffer? Is there any better
> ways?

Why do you think you're going to lose data? I would suggest using at
least a 4Kb buffer unless you have some special reason to use a smaller one.
A 1Kb buffer may mean more calls to 'recv' than a 4Kb buffer, so performance
may suffer.

DS

[roy]

Hi,

Yeah, I am using gcc compile tool.

I am developing the code for the client, send the request to the
server and get the data, Telnet protocol is implemented here.
1)The reason for flushing the receive buffer is that I am worrying
about conflicts between two reads, which means if the first time the
recv buf got 900bytes, and the second time just 100bytes, is there any
conflicts here?
2)After the client sent the request to server, the data is sent
continuouly from server, I want to get the data, do processing, and
get the new data, which is sth like a close loop control (feedback)
system. In this case, if the client receive is not bigger enough or
not grab the data in time, some data will be lost.

Thanks a lot.
Roy

[David Schwartz]

"roy" <roy_liao2001@yahoo.ca> wrote in message
news:5c23f6ff.0307161014.200e25ff@posting.google.c om...

> For the second one, during debugging, I found the receive buffer was
> full sometimes, recv() function may discard some data in case of
> overflow?

Your question doesn't make sense. Assuming the receive buffer is full,
why would the 'recv' function discard any data?

> Or due to TCP flow control, the data won't be sent out from
> server in case of client recv buf is full?

The TCP implementation can do any number of things, but it won't lose
data unless it's broken.

DS

[Barry Margolin]

In article <5c23f6ff.0307171036.2ad6159a@posting.google.com >,
roy <roy_liao2001@yahoo.ca> wrote:

>I am using
>
>char receiveBuf[];
>recv(handle, receiveBuf, length, 0);
>
>Here, receiveBuf is what I am talking about. It's program's buffer.
>For now, length=1024, shall I make it longer? How do I select the
>value of length?

You need to specify a size in the array declaration. Length should be
whatever that size is. E.g.

#define RCVBUFSIZE 1024
char receiveBuf[RCVBUFSIZE];
int bytes_read;
bytes_read = recv(handle, receiveBuf, RCVBUFSIZE, 0);

If the sender sends more than 1024 bytes, you should call recv() in a loop,
getting up to 1024 bytes each time. bytes_read will contain tha number of
bytes that were returned in each call.

Nothing will ever be lost, you just may have to call recv() several times
to get it all.

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[David Schwartz]

"roy" <roy_liao2001@yahoo.ca> wrote in message
news:5c23f6ff.0307171036.2ad6159a@posting.google.c om...

> char receiveBuf[];
> recv(handle, receiveBuf, length, 0);

> Here, receiveBuf is what I am talking about. It's program's buffer.
> For now, length=1024, shall I make it longer? How do I select the
> value of length?

It depends upon three factors:

One is the protocol. If the protocol consists of very short messages
that almost always require a reply before the protocol can continue, then
larger buffers won't matter because there will almost never be much data
pending.

Two is memory availability. If you're handling 10,000 connections, using
a 64Kb buffer might not be very practical if you use a different buffer for
each connection. If you use one buffer for all connections, then this isn't
much of an issue, but you have to store the 'leftovers' (data you read but
can't use immediately) somewhere.

Last is performance. If you use a 1Kb buffer, you may need to call
'recv' up to twice as many times as if you use a 2Kb buffer. You may also
need to enter your buffer processing code twice as many times (though with
half as much data each time). So larger buffers generally equate to higher
performance.

Here are some rules of thumb:

First, if the protocol your using has some limit on how large a single
command/transaction can be, try to pick a buffer size larger than that
limit. Otherwise, you may get a situation where your buffer is full buy you
have to read more data from the socket before you can process any of it.
Ouch.

Otherwise, 8Kb should be enough to get maximum performance. The cost of
copying/processing 4Kb or more of data probably drowns out the cost of a
system call. Plus, 8Kb is sufficiently larger than common packet sizes that
it's unlikely a larger buffer will actually receive any more data at one
time anyway.

Lastly, if there's some reason you want to go lower than 8Kb, don't go
below 2Kb. Typical MTU sizes are around 1,500 bytes and getting too close to
(or below) the MTU will cause excessive generation of small packets and
excessive Nagling (increased latency due to suboptimal prediction of future
data sizes).

If you know you are or might be dealing with larger MTUs along the whole
path, say GigE with jumbo frames, and your protocol may require sending
large amounts of data in one direction without waiting for data in the other
direction, it may make sense to use much larger buffer sizes, up to twice
the maximum frame size.

DS