Home > Archive > Unix Programming > January 2008 > Socket Question
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]
|
|
|
| Hi,
If using UNIX sockets, and my clients maximum recv() buffer data size
is 1024 bytes, and my server has say 5200 bytes to send, will my
clients recv buffer be full each time? Specifically i have recv()
going round in a loop and i want to know if a buffer with less than
1024 bytes in, is the end of a transmission?
So could i expect to receive 4 lots of data at 1024bytes + a small
remainder, or is this not something i can depend on to determine the
end of a transmission?
Going into more detail, my packets do have a termination point which
is indicated by a '.' on a line by itself, I check for this by
verifying 5 characters at the end of each recv() buffer which are
<CR><LF>.<CR><LF>. However, if my recv() buffer is < 5 characters i
get stuck in another iteration of the loop in a blocking recv() call
with no data to receive... So can i safely assume if the buffer
received from recv() is less that the max buffer size (i.e < 5 bytes
of a 1024 byte buffer) then its the end of a transmission?
Thanks for any help,
Jack
| |
| Frank Cusack 2008-01-31, 7:27 pm |
| On Thu, 31 Jan 2008 11:20:46 -0800 (PST) Jason <jecheney@gmail.com> wrote:
> If using UNIX sockets, and my clients maximum recv() buffer data size
> is 1024 bytes, and my server has say 5200 bytes to send, will my
> clients recv buffer be full each time? Specifically i have recv()
> going round in a loop and i want to know if a buffer with less than
> 1024 bytes in, is the end of a transmission?
You can't depend on that.
> So could i expect to receive 4 lots of data at 1024bytes + a small
> remainder, or is this not something i can depend on to determine the
> end of a transmission?
You cannot expect that.
If you use SOCK_DGRAM sockets you are guaranteed to receive the entire
message in one go. So if the client sends 5200 bytes at once, the server
is guaranteed to receive 5200 bytes (at once) or nothing. But there
is no reliability; you have to handle retransmission, etc. yourself.
If you use SOCK_STREAM sockets the data sent is just a stream of bytes
with no record markers and no guarantee of receiving any certain number
of bytes at a time. But you are guaranteed to receive all the data in
order even if it is broken up and misordered during transmission. In
this case you probably need a loop and once you have received more than
5 bytes you have to start checking the data at the end of the stream
to see if it is your "record" terminator.
-frank
| |
| David Schwartz 2008-01-31, 7:27 pm |
| On Jan 31, 11:20 am, Jason <jeche...@gmail.com> wrote:
> If using UNIX sockets, and my clients maximum recv() buffer data size
> is 1024 bytes, and my server has say 5200 bytes to send, will my
> clients recv buffer be full each time? Specifically i have recv()
> going round in a loop and i want to know if a buffer with less than
> 1024 bytes in, is the end of a transmission?
Nope. Imagine, for example, if some link in-between the two computers
has a maximum packet size such that only 512 bytes of TCP data fit in
a packet. Your 'recv' may get called after only the first packet has
been received, and you will get 512 bytes.
> So could i expect to receive 4 lots of data at 1024bytes + a small
> remainder, or is this not something i can depend on to determine the
> end of a transmission?
It is absolutely not something you can depend upon. In fact, you
explicitly *cannot* depend on it.
> Going into more detail, my packets do have a termination point which
> is indicated by a '.' on a line by itself, I check for this by
> verifying 5 characters at the end of each recv() buffer which are
> <CR><LF>.<CR><LF>. However, if my recv() buffer is < 5 characters i
> get stuck in another iteration of the loop in a blocking recv() call
> with no data to receive... So can i safely assume if the buffer
> received from recv() is less that the max buffer size (i.e < 5 bytes
> of a 1024 byte buffer) then its the end of a transmission?
No, that's not how you do this. You call 'recv' in a loop and after
each 'recv', you check if you have a complete data unit. If you do,
you process it, and save any leftover for the next time around.
Note that you might get the '<CR><LF>.' in one call to 'recv' and the
following '<CR><LF>' in the next. So your code should look like this:
1) Call 'recv'.
2) Check for any error or reason to abort.
3) Append received data onto any data we already had.
4) If we do not have a complete processable unit in the data we have
already received, go to step 1.
5) Process the data.
6) If we have any leftover, save it. Otherwise, empty the received
data.
7) Go to step 1.
DS
| |
| Rick Jones 2008-01-31, 7:27 pm |
| Jason <jecheney@gmail.com> wrote:
> If using UNIX sockets
To meaning to imply there would be a difference in the answer, but do
you mean AF_INET sockets in a Unix or Unix-like OS, or do you mean
AF_UNIX sockets?
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
| |
| Rick Jones 2008-01-31, 7:27 pm |
| Rick Jones <rick.jones2@hp.com> wrote:
> To meaning to imply there would be a difference in the answer, but do
Not meaning to imply...
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
|
|
|
|
|