Help regarding recv function call
Gaurav
I am using recv function call to recv mesgs. But if the server sends
more than one packet continuously immediately, then, I am recieving
packets of size = size of one packet * no of packets recieved. i.e. If
5 packets , each of size 60 bytes are sent, the client is recieving
only a single (ONE) packet of size 300 bytes !
Is there any way to differentiate these packets ? Which function call I
should use to get the packets one by one so that I can process each
packet separately ?
Please help me out.
Thanks in advance.
Gaurav
Phil Frisbie, Jr.
> Hi ,
> I am using recv function call to recv mesgs. But if the server sends
> more than one packet continuously immediately, then, I am recieving
> packets of size = size of one packet * no of packets recieved. i.e. If
> 5 packets , each of size 60 bytes are sent, the client is recieving
> only a single (ONE) packet of size 300 bytes !
Yes, the 'TCP is a stream protocol and not packets' reality has just hit you!
This question is asked and answered almost weekly...
> Is there any way to differentiate these packets ?
Yes, just add it to your protocol.
> Which function call I
> should use to get the packets one by one so that I can process each
> packet separately ?
You must add your own code to do that. Try reading this:
http://tangentsoft.net/wskfaq/articles/effective-tcp.html
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
David Schwartz
"Gaurav" <Gaurav...@gmail.com> wrote in message
news:1141243282.1...@j33g2000cwa.googlegroups.com...
Packets are the thing that travels over the wire to get your data from
one end to the other. If you're thinking about packets as you develop an
application, you are doing something horribly wrong. When you develop a
computer, you shouldn't be thinking about the power plant that produces the
power to run it.
DS
Michael K. O'Neill
> I am using recv function call to recv mesgs. But if the server sends
> more than one packet continuously immediately, then, I am recieving
> packets of size = size of one packet * no of packets recieved. i.e. If
> 5 packets , each of size 60 bytes are sent, the client is recieving
> only a single (ONE) packet of size 300 bytes !
>
As indicated by the posts above, this is one of the ways that TCP is
expected to work.
It's also possible that you might recv() six packets of 50 bytes each, or a
one packet of 200 bytes followed by two of 50 bytes, or any conceivable
combination that totals to the original 300 bytes that were streamed out of
the sending machine.
David Schwartz
"Michael K. O'Neill" <MikeAT...@nospam.hotmail.com> wrote in message
news:r%qNf.42818$H71....@newssvr13.news.prodigy.com...
> As indicated by the posts above, this is one of the ways that TCP is
> expected to work.
>
> It's also possible that you might recv() six packets of 50 bytes each, or
> a
> one packet of 200 bytes followed by two of 50 bytes, or any conceivable
> combination that totals to the original 300 bytes that were streamed out
> of
> the sending machine.
Do not say "packets". Call them "chunks" or something.
DS
Gaurav
Thanks for the the reply. Let me explain little bit more. I am using
UNIX DOMAIN stream sockets. The thing is that I cant add any prefix or
delimiter to support the protocol as the server is not in my control.
Also, the application is having 18 threads running .
I want to know if is there any other way of handling the above problem
, rather than updating the protocol ? ( I meant can it be handled using
semaphores (not sure ) !)
best rgds,
Gauarv
Peter Duniho
> Thanks for the the reply. Let me explain little bit more. I am using
> UNIX DOMAIN stream sockets.
This is a Winsock newsgroup. If you aren't using Winsock, this may not be
the best place for your questions.
That said, the network protocol is TCP, correct? The socket implementation
isn't relevant. TCP is a stream, and I suspect that Unix Domain stream
sockets work just like stream sockets in Winsock.
> The thing is that I cant add any prefix or
> delimiter to support the protocol as the server is not in my control.
What is the protocol? Why does the protocol use a streaming protocol
without defining any way to delimit the data?
> Also, the application is having 18 threads running .
Threading is irrelevant.
> I want to know if is there any other way of handling the above problem
> , rather than updating the protocol ? ( I meant can it be handled using
> semaphores (not sure ) !)
Semaphores? Why would those help?
In any case, the answer is "no". TCP is a stream protocol. Anyone using
TCP must provide a way to delimit the data. Some common methods include
having each logical message be a predetermined length, preceding the data
with a byte count, terminating each logical message with a specific
delimiter, and only sending a single logical message per connection.
But regardless of the method used, the receiver MUST have some way to
determine the length of each logical message, because the divisions between
logical messages are not preserved by TCP. You simply cannot use TCP and
expect your data to arrive in the same chunks in which they were sent.
Pete