seq in tcp protocol

seq in tcp protocol

[ishare]

  If I send a  buffer with tcp protocol , the data is separated to serveral packets ,
  each packet will have a seq number with it ,which ensures the recipient read this buffer
  in right orfer .

  my question is : how the recipient know which is the end packet of this queue ? Is there 
  data indicate the total quantity of packets composing this buffer ?


  thanks!  
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[Kristof Provost]

On 2013-03-22 21:30:08 (+0800), ishare <june.tune.sea@gmail.com> wrote:
>   If I send a  buffer with tcp protocol , the data is separated to serveral packets ,
>   each packet will have a seq number with it ,which ensures the recipient read this buffer
>   in right orfer .
> 
>   my question is : how the recipient know which is the end packet of this queue ? Is there 
>   data indicate the total quantity of packets composing this buffer ?
> 
TCP is a stream protocol. There is no concept (at the application level
anyway) of packets in TCP. The receiving TCP/IP stack is free to offer
the data to the application whenever it decides to, in however many
lumps as it decides to. Similarly, the sending TCP/IP stack may decide
to wait to send data until it's received more from the sending
application before packaging it and sending it to the receiver.

You may find http://en.wikipedia.org/wiki/Nagle%27s_algorithm
interesting.

Regards,
Kristof

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[ishare]

On Sat, Mar 23, 2013 at 02:31:18PM +0100, Kristof Provost wrote:
> On 2013-03-22 21:30:08 (+0800), ishare <june.tune.sea@gmail.com> wrote:
> >   If I send a  buffer with tcp protocol , the data is separated to serveral packets ,
> >   each packet will have a seq number with it ,which ensures the recipient read this buffer
> >   in right orfer .
> > 
> >   my question is : how the recipient know which is the end packet of this queue ? Is there 
> >   data indicate the total quantity of packets composing this buffer ?
> > 
> TCP is a stream protocol. There is no concept (at the application level
> anyway) of packets in TCP. The receiving TCP/IP stack is free to offer
> the data to the application whenever it decides to, in however many
> lumps as it decides to. Similarly, the sending TCP/IP stack may decide
> to wait to send data until it's received more from the sending
> application before packaging it and sending it to the receiver.

  When one  send  system api is called , will  all  data in the buffer 
  be sent out together at one time ?

  
> 
> You may find http://en.wikipedia.org/wiki/Nagle%27s_algorithm
> interesting.
> 
> Regards,
> Kristof
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[Kristof Provost]

On 2013-03-24 11:29:32 (+0800), ishare <june.tune.sea@gmail.com> wrote:
> > TCP is a stream protocol. There is no concept (at the application level
> > anyway) of packets in TCP. The receiving TCP/IP stack is free to offer
> > the data to the application whenever it decides to, in however many
> > lumps as it decides to. Similarly, the sending TCP/IP stack may decide
> > to wait to send data until it's received more from the sending
> > application before packaging it and sending it to the receiver.
> 
>   When one  send  system api is called , will  all  data in the buffer 
>   be sent out together at one time ?
> 
No. There are no guarantees about how many TCP packets will be used to
send your data, or in how many buffers it will be offered to the
application on the receiving side.

Kristof

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[Aniruddha Bhattacharyya]

FIN flag is set to terminate a TCP session, similarly SYN flag is set
to indicate beginning of a TCP transmission.
So stream tear-down is initiated as soon as receiver gets a packet
with FIN flag set to 1. Though there are some intricacy and variation
of it.

http://www.fluffyspider.com/resources/papers/TTCPIMG00011.GIF


http://www.fluffyspider.com/resources/papers/t_tcp.html

On Sun, Mar 24, 2013 at 8:59 AM, ishare <june.tune.sea@gmail.com> wrote:
> On Sat, Mar 23, 2013 at 02:31:18PM +0100, Kristof Provost wrote:
>> On 2013-03-22 21:30:08 (+0800), ishare <june.tune.sea@gmail.com> wrote:
>> >   If I send a  buffer with tcp protocol , the data is separated to serveral packets ,
>> >   each packet will have a seq number with it ,which ensures the recipient read this buffer
>> >   in right orfer .
>> >
>> >   my question is : how the recipient know which is the end packet of this queue ? Is there
>> >   data indicate the total quantity of packets composing this buffer ?
>> >
>> TCP is a stream protocol. There is no concept (at the application level
>> anyway) of packets in TCP. The receiving TCP/IP stack is free to offer
>> the data to the application whenever it decides to, in however many
>> lumps as it decides to. Similarly, the sending TCP/IP stack may decide
>> to wait to send data until it's received more from the sending
>> application before packaging it and sending it to the receiver.
>
>   When one  send  system api is called , will  all  data in the buffer
>   be sent out together at one time ?
>
>
>>
>> You may find http://en.wikipedia.org/wiki/Nagle%27s_algorithm
>> interesting.
>>
>> Regards,
>> Kristof
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[ishare]

 How does the sender decide how many packet is needed to transfer one buffer and 
 manager the seq orders of them ?

 thanks! 
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[Kristof Provost]

On 2013-03-24 19:57:11 (+0800), ishare <june.tune.sea@gmail.com> wrote:
> 
>  How does the sender decide how many packet is needed to transfer one buffer and 
>  manager the seq orders of them ?
> 
http://en.wikipedia.org/wiki/Nagle%27s_algorithm

-- 
Kristof

--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: seq in tcp protocol

[Anatoliy Sivov]

I could be wrong, but I guess linux uses Minshall's modification of  
Nagle's algorithm.


>>
>>  How does the sender decide how many packet is needed to transfer one  
>> buffer and
>>  manager the seq orders of them ?
>>
> http://en.wikipedia.org/wiki/Nagle%27s_algorithm
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs