Re: Winsock recv() and unfragmented packets
- From: sra <sralpert@xxxxxxxxxxx>
- Date: Sun, 19 Apr 2009 08:10:21 -0700 (PDT)
On Apr 19, 7:44 am, re_ductor <re_duc...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Hi all,tcp is a stream. That means there is no implicit "record boundary."
I was wondering if a call to recv() will return all data for an unfragmented
packet. Suppose i'm setting up a TCP connection over the Internet, once the
connection has been established the client starts sending some data using
exactly one call to send(). (well under the 536 (576 minus 40 header bytes)
byte limit that might casue fragmentation). From what I understand this
packet shouldn't be fragmented so it'll arrive on the server in one piece..
Does this mean that when calling recv() with a large enough buffer will
return the entire packet or can winsock itself decide that i have to call
recv() more than once to get all the data to the unfragmented data?
Note that i'm fully aware of the fact that recv() can return data for more
than one packet. But i'm talking about a single call to send() that transmits
no more bytes than IP's fragmentaiton limit and then simply waits for the
server to reply. So it should make sense (From TCP/IP's standpoint of view at
least) that a call to recv() with a large enough buffer returns all the data,
is this assumption correct?
You should not rely on it. You also don't know what kind of buffering
the OS on the server might do. There are many vagaries involved, for
example, when the server writes the data, does it go into small
buffers in the OS and maybe sent while the process is swapped out? If
you really want packets, you have to code for it. You can use udp in
place of tcp but you give up a lot of useful functionality to do that.
/steveA
.
- References:
- Winsock recv() and unfragmented packets
- From: re_ductor
- Winsock recv() and unfragmented packets
- Prev by Date: Winsock recv() and unfragmented packets
- Next by Date: Re: Force IP packets on the wire.
- Previous by thread: Winsock recv() and unfragmented packets
- Next by thread: LSP not loaded by inetinfo.exe or svchost.exe
- Index(es):
Relevant Pages
|
