One connection many packets? - TCP-IP

This is a discussion on One connection many packets? - TCP-IP ; Hi, I would like to know how one usually connect computers via tcp/ip. Or more specifically how many connections you normally make to transmit data. Until now I have always made one connection with the remote host and then been ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: One connection many packets?

  1. One connection many packets?

    Hi,

    I would like to know how one usually connect computers via tcp/ip. Or
    more specifically how many connections you normally make to transmit
    data. Until now I have always made one connection with the remote host
    and then been sending packet after packet without ever closing the
    connection.
    But after recent closer study of for instance the recv() function in
    winsock I can see that it never returns unless there is new data or
    the connection is closed (I think the functionality is the same in
    linux and unix). This leads me to believe that one should close the
    connection after each packet, because otherwise you would have to
    indicate in the packet itself when it has been fully collected, or you
    would get stuck on the recv as soon as all parts of the current packet
    has been collected.
    Is this the way it's made? I've never had any tutoring in this, I'm
    just doing what seems to work, and this far it's been working with
    only one connection, although the receiving of data is perhaps
    unnecessary complex in this case?
    I have always had a size field in the packets so I know when to stop
    trying to collect more of the packet via the recv function, but this
    seems like a waste of space as this information should be present in
    the tcp/ip packet itself.

  2. Re: One connection many packets?

    andreas.zetterstrom@gmail.com writes:

    > But after recent closer study of for instance the recv() function in
    > winsock I can see that it never returns unless there is new data or
    > the connection is closed (I think the functionality is the same in
    > linux and unix).



    Normally when the sender writes (say) a 8K chunk of data, it is split
    up into several packets. The last one has the PSH bit set.

    This PSH tells the receiver that the data should be made available to
    the application waiting for it. So the stack makes the 8K available in
    a buffer, and wakes up the application, which can read the data.


    --
    Posted via a free Usenet account from http://www.teranews.com


  3. Re: One connection many packets?

    On 12 Dec, 13:46, Bruce Barnett
    wrote:
    > andreas.zetterst...@gmail.com writes:
    > > But after recent closer study of for instance the recv() function in
    > > winsock I can see that it never returns unless there is new data or
    > > the connection is closed (I think the functionality is the same in
    > > linux and unix).

    >
    > Normally when the sender writes (say) a 8K chunk of data, it is split
    > up into several packets. The last one has the PSH bit set.
    >
    > This PSH tells the receiver that the data should be made available to
    > the application waiting for it. So the stack makes the 8K available in
    > a buffer, and wakes up the application, which can read the data.
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Yes I have noticed this functionality. From what I understand the recv
    command gives these pieces one by one, ie. you will have to call the
    recv multiple times to get all the 8K data if it got split up by the
    TCP/IP protocol.
    The problem is to know when to stop, because the recv command will
    block if there is no data (which is perfectly logical).
    I want to get all the data, but not get "too much" data as that
    instead will lock the application. Unfortunately there is no way to
    discover the PSH bit from the recv command as far as I know, so I
    thought perhaps the normal thing to do is to close the connection
    after each chuck of data, which results in recv returning a 0
    indicating the connection was closed, which is easily detected by a
    program.

  4. Re: One connection many packets?

    On 12 Dec, 15:39, andreas.zetterst...@gmail.com wrote:
    > On 12 Dec, 13:46, Bruce Barnett
    >
    >
    >
    > wrote:
    > > andreas.zetterst...@gmail.com writes:
    > > > But after recent closer study of for instance the recv() function in
    > > > winsock I can see that it never returns unless there is new data or
    > > > the connection is closed (I think the functionality is the same in
    > > > linux and unix).

    >
    > > Normally when the sender writes (say) a 8K chunk of data, it is split
    > > up into several packets. The last one has the PSH bit set.

    >
    > > This PSH tells the receiver that the data should be made available to
    > > the application waiting for it. So the stack makes the 8K available in
    > > a buffer, and wakes up the application, which can read the data.

    >
    > > --
    > > Posted via a free Usenet account fromhttp://www.teranews.com

    >
    > Yes I have noticed this functionality. From what I understand the recv
    > command gives these pieces one by one, ie. you will have to call the
    > recv multiple times to get all the 8K data if it got split up by the
    > TCP/IP protocol.
    > The problem is to know when to stop, because the recv command will
    > block if there is no data (which is perfectly logical).
    > I want to get all the data, but not get "too much" data as that
    > instead will lock the application. Unfortunately there is no way to
    > discover the PSH bit from the recv command as far as I know, so I
    > thought perhaps the normal thing to do is to close the connection
    > after each chuck of data, which results in recv returning a 0
    > indicating the connection was closed, which is easily detected by a
    > program.


    After some more study I think I misstakedly assumed that recv()
    returns after each block of data sent through TCP/IP. What I observed
    as splitted data was due to the recv buffer being full. Thus this is
    not something that is connected to TCP/IP at all but rather the
    implementation of recv. I'll just drop the subject.

  5. Re: One connection many packets?

    Bruce Barnett wrote:
    > Normally when the sender writes (say) a 8K chunk of data, it is
    > split up into several packets.


    Which in the context of TCP are called segments. Might as well
    teach the terminology

    > The last one has the PSH bit set.


    > This PSH tells the receiver that the data should be made available
    > to the application waiting for it. So the stack makes the 8K
    > available in a buffer, and wakes up the application, which can read
    > the data.


    Should make the data available, *if it hasn't done so already*. The
    description as written above could be mistakenly interpreted as
    meaning one could post an 8K recv() on the receiver's end and have it
    only complete once the segment with the PSH bit set arrived, which is
    of course _not_ what will happen. 99 times out of ten, when the first
    segment arrives, the receiving application will be notified - either
    coming out of select/poll/whatever, or the recv() call completing with
    just that segment's worth of data.

    The whole "TCP is a byte stream" bit...

    rick jones
    --
    portable adj, code that compiles under more than one compiler
    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...

  6. Re: One connection many packets?

    andreas.zetterstrom@gmail.com writes:

    > After some more study I think I misstakedly assumed that recv()
    > returns after each block of data sent through TCP/IP. What I observed
    > as splitted data was due to the recv buffer being full. Thus this is
    > not something that is connected to TCP/IP at all but rather the
    > implementation of recv. I'll just drop the subject.


    Check the Stevens book for some sample code.
    You might see the PSH bit if you read 16K, and the sender sends 4K.

    --
    Posted via a free Usenet account from http://www.teranews.com


  7. Re: One connection many packets?

    On 12 Dec, 19:57, Bruce Barnett
    wrote:
    > andreas.zetterst...@gmail.com writes:
    > > After some more study I think I misstakedly assumed that recv()
    > > returns after each block of data sent through TCP/IP. What I observed
    > > as splitted data was due to the recv buffer being full. Thus this is
    > > not something that is connected to TCP/IP at all but rather the
    > > implementation of recv. I'll just drop the subject.

    >
    > Check the Stevens book for some sample code.
    > You might see the PSH bit if you read 16K, and the sender sends 4K.
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Thanks all for the help. I think the main issue I was having was with
    TCP/IP being stream orientated and that there is no way to know if the
    packet you sent on the sender side really has appeared in all its
    glory on the receiver side without anything added in the packet itself
    that indicates how big it is. I have now surrendered to this fact and
    add a special delimiter char at the end of each packet

  8. Re: One connection many packets?

    andreas.zetterstrom@gmail.com writes:

    > I have now surrendered to this fact and
    > add a special delimiter char at the end of each packet


    Been there. Done that. :-)

    --
    Posted via a free Usenet account from http://www.teranews.com


  9. Re: One connection many packets?

    On Dec 12, 6:39 am, andreas.zetterst...@gmail.com wrote:

    > Yes I have noticed this functionality. From what I understand the recv
    > command gives these pieces one by one, ie. you will have to call the
    > recv multiple times to get all the 8K data if it got split up by the
    > TCP/IP protocol.
    > The problem is to know when to stop, because the recv command will
    > block if there is no data (which is perfectly logical).


    Stop if you get all the data you need to make further progress. Don't
    stop if you haven't.

    > I want to get all the data, but not get "too much" data as that
    > instead will lock the application. Unfortunately there is no way to
    > discover the PSH bit from the recv command as far as I know, so I
    > thought perhaps the normal thing to do is to close the connection
    > after each chuck of data, which results in recv returning a 0
    > indicating the connection was closed, which is easily detected by a
    > program.


    No, that's a very inefficient way to do it. The basic idea is to write
    your code like this:

    1) Call 'recv', adding that data to any data we had lefover.

    2) If we don't have at least one complete unit of data, go to step 1.

    3) Process all complete units of data we have received, save any
    leftover.

    4) Go to step 1.

    The way you tell if you have a complete unit of data depends on the
    protocol. For SMTP, it's if you have at least one newline or line feed
    in the received data. For HTTP, it's whether you have a complete
    request based on the HTTP specification.

    Line-oriented protocols are probably the simplest. Another common
    solution is to send the length of the subsequent data and then send
    the data.

    DS

  10. Re: One connection many packets?

    On Dec 12, 10:22 am, Rick Jones wrote:

    > Should make the data available, *if it hasn't done so already*. The
    > description as written above could be mistakenly interpreted as
    > meaning one could post an 8K recv() on the receiver's end and have it
    > only complete once the segment with the PSH bit set arrived, which is
    > of course _not_ what will happen. 99 times out of ten, when the first
    > segment arrives, the receiving application will be notified - either
    > coming out of select/poll/whatever, or the recv() call completing with
    > just that segment's worth of data.
    >
    > The whole "TCP is a byte stream" bit...


    And, of course, if you make a 1Kb send and then another 200 byte send,
    and they wind up in a single segment, whether or not the PSH bit is
    set, there's no way to find the boundary between the two.

    DS

+ Reply to Thread