recvfrom() strange operation - Linux

This is a discussion on recvfrom() strange operation - Linux ; Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5 I send one packet trough SOCK_DGRAM socket (UDP) like this sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn); On a receiver sied in case of: recvfrom(sockfd,p,16,0,xxx,nnn); the p contain "abcdefghijklmnop" but in case of: recvfrom(sockfd,p,1,0,xxx,nnn); recvfrom(sockfd,q,15,0,xxx,nnn); the p contain ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: recvfrom() strange operation

  1. recvfrom() strange operation

    Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5

    I send one packet trough SOCK_DGRAM socket (UDP) like this
    sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn);

    On a receiver sied in case of:
    recvfrom(sockfd,p,16,0,xxx,nnn);
    the p contain "abcdefghijklmnop"
    but in case of:
    recvfrom(sockfd,p,1,0,xxx,nnn);
    recvfrom(sockfd,q,15,0,xxx,nnn);
    the p contain "a"
    the q is empty (insted of "bcdefghijklmnop")
    If I use SOCK_STREAM (TCP) ths same code working fine.

    This mean for me some defragmentatnion missing from kernel. This is
    strange because the fragmentation is implemented in transmit side (I
    can send the sample packet with 16 time sendto()).
    Anybody has idea how to I solve this problem?
    In my live code of course mouch complex and working longer datas, so
    this is a sample only.


  2. Re: recvfrom() strange operation

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    kzsolt@datanet.hu wrote:
    > Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5
    >
    > I send one packet trough SOCK_DGRAM socket (UDP) like this
    > sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn);
    >
    > On a receiver sied in case of:
    > recvfrom(sockfd,p,16,0,xxx,nnn);
    > the p contain "abcdefghijklmnop"
    > but in case of:
    > recvfrom(sockfd,p,1,0,xxx,nnn);
    > recvfrom(sockfd,q,15,0,xxx,nnn);
    > the p contain "a"
    > the q is empty (insted of "bcdefghijklmnop")
    > If I use SOCK_STREAM (TCP) ths same code working fine.
    >
    > This mean for me some defragmentatnion missing from kernel.

    [snip]

    No, it doesn't mean that. It means that you have misunderstood the
    purpose of recvfrom() and it's use with UDP.

    UDP is not a stream protocol. Instead, it transfers atomic blocks of
    data. You send a block; you receive a block. You /can't/ receive a
    partial block (at least, not at the sockets API level).

    With your sendto() call, you sent 16 bytes of data in a single block

    With your first recvfrom() call,
    > recvfrom(sockfd,p,16,0,xxx,nnn);

    you asked for sockets to grab the next block of data, and put it in a
    16 byte buffer, which it did.

    With your second and third recvfrom() calls,
    > recvfrom(sockfd,p,1,0,xxx,nnn);
    > recvfrom(sockfd,q,15,0,xxx,nnn);

    you first asked sockets to grab the next block of data (16 bytes from
    your sendto() call) and put it in a 1 byte buffer. Of course, 16 bytes
    of data cant fit into a 1 byte buffer, so sockets only put the first
    byte of the 16 byte block into the buffer /and discarded the rest/ as
    per your (implicit) instructions.
    You then attempted to receive another block of data and put it into a
    15 byte buffer. Apparently, there was no more data, and the recvfrom()
    didn't put anything into your buffer. I take it you used a non-blocking
    socket, otherwsie recvfrom() would have waited for the next packet, and
    given you the first 15 bytes of it's data.

    You probably should reread the manpage for recvfrom(2) ("man 2
    recvfrom") and review both it's return value (the length of data
    retrieved or -1 for error) and behaviour of recvfrom() in the face of a
    short buffer
    quote:
    All three routines return the length of the message on
    successful completion. If a message is too long to fit in
    the supplied buffer, excess bytes may be discarded depend*
    ing on the type of socket the message is received from
    (see socket(2)).
    end quote

    HTH
    - --
    Lew Pitcher



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

    iD8DBQFFAFQJagVFX4UWr64RAv6dAJsHmyyPIRht12Y1I3H/lXfeEeqA1QCgqJ22
    5DWtZS4YsWCt44rrmnnIcqI=
    =HMta
    -----END PGP SIGNATURE-----


  3. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5
    >
    > I send one packet trough SOCK_DGRAM socket (UDP) like this
    > sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn);
    >
    > On a receiver sied in case of:
    > recvfrom(sockfd,p,16,0,xxx,nnn);
    > the p contain "abcdefghijklmnop"
    > but in case of:
    > recvfrom(sockfd,p,1,0,xxx,nnn);
    > recvfrom(sockfd,q,15,0,xxx,nnn);
    > the p contain "a"
    > the q is empty (insted of "bcdefghijklmnop")
    > If I use SOCK_STREAM (TCP) ths same code working fine.
    >


    >From the recvfrom() man page:

    If a message is too long to fit in the supplied buffer,
    excess bytes may be discarded depending on the type of
    socket the message is received from (see socket(2))

    and from the socket man page:
    SOCK_SEQPACKET sockets employ the same system calls as
    SOCK_STREAM sockets. The only difference is that read(2) calls
    will return only the amount of data requested, and any remaining in
    the arriving packet will be discarded. Also all message boundaries
    in incoming datagrams are preserved.

    No specific mention of SOCK_DGRAM discarding excess data, but
    you emperical evidence would suggest that it does. You'd have to
    look at the kernel source to see for sure, but it looks like you can't
    control this. Any reason not go always supply a buffer at least
    as big as your datagram?

    Regards,
    Steve
    ------------------------------------------------------------------------
    Steve Schefter phone: +1 705 725 9999 x26
    The Software Group Limited fax: +1 705 725 9666
    642 Welham Road,
    Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com


  4. Re: recvfrom() strange operation

    So gentlemans first thank you for all of the answers!

    "Any reason not go always supply a buffer at least as big as your
    datagram?"
    Our application is a reliable protocol running in separated threads and
    theoretically working over TCP and UDP too. If I have no chance to
    retrive packet content by bytes then the only way is implement
    additional buffering. But this buffering is triple buffering in our
    stack instead of double buffering. This cost mouch CPU and time too.
    And of course I write the same algorithm already in the kernel...

    No matter the data arrived over TCP or UDP, arrived in packet (more
    than one octett units). In case of TCP implement buffering and I can
    retrive packet data as byte, but in case of UDP not. I think the
    buffering calls missing from the UDP path.

    steve_schefter@hotmail.com írta:
    > kzsolt@datanet.hu wrote:
    > > Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5
    > >
    > > I send one packet trough SOCK_DGRAM socket (UDP) like this
    > > sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn);
    > >
    > > On a receiver sied in case of:
    > > recvfrom(sockfd,p,16,0,xxx,nnn);
    > > the p contain "abcdefghijklmnop"
    > > but in case of:
    > > recvfrom(sockfd,p,1,0,xxx,nnn);
    > > recvfrom(sockfd,q,15,0,xxx,nnn);
    > > the p contain "a"
    > > the q is empty (insted of "bcdefghijklmnop")
    > > If I use SOCK_STREAM (TCP) ths same code working fine.
    > >

    >
    > >From the recvfrom() man page:

    > If a message is too long to fit in the supplied buffer,
    > excess bytes may be discarded depending on the type of
    > socket the message is received from (see socket(2))
    >
    > and from the socket man page:
    > SOCK_SEQPACKET sockets employ the same system calls as
    > SOCK_STREAM sockets. The only difference is that read(2) calls
    > will return only the amount of data requested, and any remaining in
    > the arriving packet will be discarded. Also all message boundaries
    > in incoming datagrams are preserved.
    >
    > No specific mention of SOCK_DGRAM discarding excess data, but
    > you emperical evidence would suggest that it does. You'd have to
    > look at the kernel source to see for sure, but it looks like you can't
    > control this. Any reason not go always supply a buffer at least
    > as big as your datagram?
    >
    > Regards,
    > Steve
    > ------------------------------------------------------------------------
    > Steve Schefter phone: +1 705 725 9999 x26
    > The Software Group Limited fax: +1 705 725 9666
    > 642 Welham Road,
    > Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com



  5. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > "Any reason not go always supply a buffer at least as big as your
    > datagram?"
    > Our application is a reliable protocol running in separated threads and
    > theoretically working over TCP and UDP too. If I have no chance to
    > retrive packet content by bytes then the only way is implement
    > additional buffering. But this buffering is triple buffering in our
    > stack instead of double buffering. This cost mouch CPU and time too.


    Not sure what you mean by buffering, but since you indicate that
    it has a CPU overhead, I'd guess you mean copying the data
    rather than just queueing. If that's the case, you might want to
    take a careful look at the design. The one copy from kernel to
    user space (in the case of incoming data) would normally be the
    only copy you need to do. Any other copying as it moves
    through the layers of the protocol stack is probably a poor
    design.

    > And of course I write the same algorithm already in the kernel...


    I don't quite follow this part either. If some code exists within
    the kernel and implements a portion of your protocol stack
    (analyzing some bytes of the message), then why would this
    same code exist within user space? And you you are
    accessing TCP/UDP using recvfrom(), what do you have in
    the kernel?

    Regards,
    Steve
    ------------------------------------------------------------------------
    Steve Schefter phone: +1 705 725 9999 x26
    The Software Group Limited fax: +1 705 725 9666
    642 Welham Road,
    Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com


  6. Re: recvfrom() strange operation

    "Any other copying as it moves through the layers of the protocol stack
    is probably a poor design."
    If you think about all of the usefull frameing algorithm you have two
    way:
    1). "other copying"
    2). read data byte by byte...

    "then why would this same code exist within user space"
    I devolped a full IP protcol stack including UDP and TCP for our
    company. This has no relation to x86 and unix kernel, but I know it
    from inside.
    To receive UDP or TCP packet you need some buffering of received data.
    This mean the packet arrived with n byte user data, and the user can
    read it sequecially by segmenets or by octetts. This is a same algo
    like you read sequecially from the file (blocks). If this algo used for
    buffering of TCP packet I do not undersatnd why not used for UDP
    packets. The result is the recv and the recvfrom working fully
    different way in case of TCP and UDP. This is like if the fread()
    working different if you read file with extension .abc than you read
    file with extension .bcd


    steve_schefter@hotmail.com írta:
    > kzsolt@datanet.hu wrote:
    > > "Any reason not go always supply a buffer at least as big as your
    > > datagram?"
    > > Our application is a reliable protocol running in separated threads and
    > > theoretically working over TCP and UDP too. If I have no chance to
    > > retrive packet content by bytes then the only way is implement
    > > additional buffering. But this buffering is triple buffering in our
    > > stack instead of double buffering. This cost mouch CPU and time too.

    >
    > Not sure what you mean by buffering, but since you indicate that
    > it has a CPU overhead, I'd guess you mean copying the data
    > rather than just queueing. If that's the case, you might want to
    > take a careful look at the design. The one copy from kernel to
    > user space (in the case of incoming data) would normally be the
    > only copy you need to do. Any other copying as it moves
    > through the layers of the protocol stack is probably a poor
    > design.
    >
    > > And of course I write the same algorithm already in the kernel...

    >
    > I don't quite follow this part either. If some code exists within
    > the kernel and implements a portion of your protocol stack
    > (analyzing some bytes of the message), then why would this
    > same code exist within user space? And you you are
    > accessing TCP/UDP using recvfrom(), what do you have in
    > the kernel?
    >
    > Regards,
    > Steve
    > ------------------------------------------------------------------------
    > Steve Schefter phone: +1 705 725 9999 x26
    > The Software Group Limited fax: +1 705 725 9666
    > 642 Welham Road,
    > Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com



  7. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > "Any other copying as it moves through the layers of the protocol stack
    > is probably a poor design."
    > If you think about all of the usefull frameing algorithm you have two
    > way:
    > 1). "other copying"
    > 2). read data byte by byte...


    3) Have the lower level of the stack read the complete message
    into a buffer accessible by all layers and then pass on the address
    of the data rather than doing a copy. That's the way most protocol
    stacks these days work.

    > "then why would this same code exist within user space"
    > I devolped a full IP protcol stack including UDP and TCP for our
    > company. This has no relation to x86 and unix kernel, but I know it
    > from inside.
    > To receive UDP or TCP packet you need some buffering of received data.
    > This mean the packet arrived with n byte user data, and the user can
    > read it sequecially by segmenets or by octetts. This is a same algo
    > like you read sequecially from the file (blocks). If this algo used for
    > buffering of TCP packet I do not undersatnd why not used for UDP
    > packets.


    That's because TCP is a streaming (byte-oriented) protocol while
    UDP is a message-oriented protocol. If the kernel did what you
    wanted, then I as a programmer could not UDP recv() and know
    that what I got was sent as a single message by the remote. I
    may need to. It's designed this way on purpose, it just doesn't
    suit your purpose.

    Reading between the lines, it appears as though you are
    moving from kernel space to user space just to be able to
    access Linux sockets. This is not necessary. You can
    access sockets in the kernel. See tux for example.

    Regards,
    Steve
    ------------------------------------------------------------------------
    Steve Schefter phone: +1 705 725 9999 x26
    The Software Group Limited fax: +1 705 725 9666
    642 Welham Road,
    Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com


  8. Re: recvfrom() strange operation

    "3) Have the ..."
    But in that case not working, because the frameing always require
    buffer scroll (for escape sequence). Other side our task is "using with
    standard calls", this mean we cannot go deeply to kernel, and we can
    migrate any time to x86solaris.

    I have only one escape way for this kind of UDP operation. In case of
    TCP receive you always send data to upper level in sequence, because
    you know the packet squence. In case of UDP you do not know the packet
    sequence, maybe at revc() octett_n and octett_n+1 sended in reverse (IP
    network nature). This is maybe the only reason why UDP do not enable to
    read packet as octett only as packet.
    But "application" can (must) discover packet squence reverse from
    octett stream, so this is pain for us....

    Other sides the UDP packet sequence problem littlebit mistificated. If
    you have complex IP network (maybe generate packet squence reverse)
    then you must use TCP instead of UDP. Otherwords in this kind of
    network UDP has more disadvantege then advantage. If you have easy
    network topology you must use UDP instead of TCP because the troughput
    advantage.
    In case of standard IP services you have no way to select which host
    use UDP and which TCP for the same service. Our application can do it.
    If a network have potential to serve it we make mouch higher troughput
    and lower delay than TCP. Our higher level applications need it...

    steve_schefter@hotmail.com írta:
    > kzsolt@datanet.hu wrote:
    > > "Any other copying as it moves through the layers of the protocol stack
    > > is probably a poor design."
    > > If you think about all of the usefull frameing algorithm you have two
    > > way:
    > > 1). "other copying"
    > > 2). read data byte by byte...

    >
    > 3) Have the lower level of the stack read the complete message
    > into a buffer accessible by all layers and then pass on the address
    > of the data rather than doing a copy. That's the way most protocol
    > stacks these days work.
    >
    > > "then why would this same code exist within user space"
    > > I devolped a full IP protcol stack including UDP and TCP for our
    > > company. This has no relation to x86 and unix kernel, but I know it
    > > from inside.
    > > To receive UDP or TCP packet you need some buffering of received data.
    > > This mean the packet arrived with n byte user data, and the user can
    > > read it sequecially by segmenets or by octetts. This is a same algo
    > > like you read sequecially from the file (blocks). If this algo used for
    > > buffering of TCP packet I do not undersatnd why not used for UDP
    > > packets.

    >
    > That's because TCP is a streaming (byte-oriented) protocol while
    > UDP is a message-oriented protocol. If the kernel did what you
    > wanted, then I as a programmer could not UDP recv() and know
    > that what I got was sent as a single message by the remote. I
    > may need to. It's designed this way on purpose, it just doesn't
    > suit your purpose.
    >
    > Reading between the lines, it appears as though you are
    > moving from kernel space to user space just to be able to
    > access Linux sockets. This is not necessary. You can
    > access sockets in the kernel. See tux for example.
    >
    > Regards,
    > Steve
    > ------------------------------------------------------------------------
    > Steve Schefter phone: +1 705 725 9999 x26
    > The Software Group Limited fax: +1 705 725 9666
    > 642 Welham Road,
    > Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com



  9. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > "3) Have the ..."
    > But in that case not working, because the frameing always require
    > buffer scroll (for escape sequence). Other side our task is "using with
    > standard calls", this mean we cannot go deeply to kernel, and we can
    > migrate any time to x86solaris.
    >
    > I have only one escape way for this kind of UDP operation. In case of
    > TCP receive you always send data to upper level in sequence, because
    > you know the packet squence. In case of UDP you do not know the packet
    > sequence, maybe at revc() octett_n and octett_n+1 sended in reverse (IP
    > network nature). This is maybe the only reason why UDP do not enable to
    > read packet as octett only as packet.
    > But "application" can (must) discover packet squence reverse from
    > octett stream, so this is pain for us....
    >
    > Other sides the UDP packet sequence problem littlebit mistificated. If
    > you have complex IP network (maybe generate packet squence reverse)
    > then you must use TCP instead of UDP. Otherwords in this kind of
    > network UDP has more disadvantege then advantage. If you have easy
    > network topology you must use UDP instead of TCP because the troughput
    > advantage.
    > In case of standard IP services you have no way to select which host
    > use UDP and which TCP for the same service. Our application can do it.
    > If a network have potential to serve it we make mouch higher troughput
    > and lower delay than TCP. Our higher level applications need it...



    When you're at it, please understand that TCP *does not* preserve
    packet boundaries. It guarantees the delivery of all input octets
    in the order they were sent, but it can transport them in any size
    of chunks it feels fit. This means that for TCP transfers you may
    need to embed packet framing in the payload.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  10. Re: recvfrom() strange operation


    Tauno Voipio wrote:

    [snip]
    > When you're at it, please understand that TCP *does not* preserve
    > packet boundaries. It guarantees the delivery of all input octets
    > in the order they were sent, but it can transport them in any size
    > of chunks it feels fit. This means that for TCP transfers you may
    > need to embed packet framing in the payload.


    And, of course, the corolary to this is that, while the receiver will
    receive everything the sender sent, in the order it sent it in, it may
    not receive it with the same boundaries as the sender sent it with.

    That is to say, if the sending program wrote 3 5-octet "packets", the
    receiver will receive 15 octets, but may receive all 15 octets at once,
    or even as 15 individual 1-octet pieces. The receiver cannot treat the
    recv() call as working on anything but a single byte boundary within a
    stream of contigious bytes, and must handle short (or long) reception
    gracefully.

    --
    Lew Pitcher


  11. Re: recvfrom() strange operation

    "When you're at it, please understand that TCP *does not* preserve
    packet boundaries"
    My opinion the TCP standard has a capability to preserve packet
    boundaries (if the UDP has). The question is how you implemet it.
    Our application use framing over TCP and UDP too. For us the packet
    boundaries not important (so mouch)...

    Tauno Voipio írta:

    >
    > When you're at it, please understand that TCP *does not* preserve
    > packet boundaries. It guarantees the delivery of all input octets
    > in the order they were sent, but it can transport them in any size
    > of chunks it feels fit. This means that for TCP transfers you may
    > need to embed packet framing in the payload.
    >
    > --
    >
    > Tauno Voipio
    > tauno voipio (at) iki fi



  12. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > Tauno Voipio írta:
    >>

    > "When you're at it, please understand that TCP *does not* preserve
    > packet boundaries"


    > My opinion the TCP standard has a capability to preserve packet
    > boundaries (if the UDP has). The question is how you implemet it.
    > Our application use framing over TCP and UDP too. For us the packet
    > boundaries not important (so mouch)...


    No, it *does not*. The *only* guarantee is that all the octets
    sent will arrive in the order they are sent.

    There are socket options which can be interpreted as
    preserving packet boundaries, but in the general case
    it is not true - do not rely on it.

    There are many applications thinking that the packet
    boundaries can be preserved (e.g. Modbus/TCP), but
    they are guaranteed to fail - sooner or later.

    It's much easier to be prepared than spoil countless
    hours of frustrating debugging to find occasional
    failures due to the fact that some node on the route
    has re-packaged your TCP stream.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  13. Re: recvfrom() strange operation

    kzsolt@datanet.hu wrote:
    > "3) Have the ..."
    > But in that case not working, because the frameing always require
    > buffer scroll (for escape sequence).


    This does not preclude avoiding a copy. You just have to handle
    "frames" (or whatever you are calling your higher layer protocol
    element) crossing UDP message boundaries.

    Or better yet, put some knowledge of the fact that you are
    using UDP into the code and your "frame" will exist entirely
    within one datagram (assuming it will fit). You then won't
    have to have escape characters to mark your frame boundaries.

    > Other side our task is "using with
    > standard calls", this mean we cannot go deeply to kernel, and we can
    > migrate any time to x86solaris.


    Clearly I'm not following something here. Earlier you complained
    about having to write the same algorithm in both kernel and user
    space and I therefore noted that you don't need to get into user
    space just to use sockets. Now you tell me that you want
    portability to x86solaris which would mean that you need to be
    doing it all in user space since there's no common DDI/DKI
    in both Linux and Solaris. So how does the need to have the
    algorithm in kernel space (and thus the duplication) come into
    it?

    > This is maybe the only reason why UDP do not enable to
    > read packet as octett only as packet.
    > But "application" can (must) discover packet squence reverse from
    > octett stream, so this is pain for us....


    We can only guess what was in the mind of the writers of IPv4,
    but I'd be more inclinded to guess that you can only read UDP as
    packet because it is a packet-based while you can read TCP as
    bytes because it is byte-based (streaming). It still sounds to me
    like you are trying to use UDP as a streaming protocol, which it
    is not.

    > Other sides the UDP packet sequence problem littlebit mistificated. If
    > you have complex IP network (maybe generate packet squence reverse)
    > then you must use TCP instead of UDP. Otherwords in this kind of
    > network UDP has more disadvantege then advantage.


    If you are relying upon the network to deliver UDP in order even for
    the simplest network, then you have a serious design flaw. You
    must always use the upper layer protocol to handle duplicated or
    mis-ordered packets when using UDP, no matter what your
    network looks like.


    Regards,
    Steve


  14. Re: recvfrom() strange operation

    First sorry for the long delay but from our coutry (hu) the sign in to
    google is inpossibile over more days (reason: page not found). I'm use
    some tricky links to sign in. This I hope work for a long time.

    "You must always use the upper layer protocol to handle duplicated or
    mis-ordered packets when using UDP, no matter what your network looks
    like."
    That is what I do. Our sfrtp has framing and retransmission capability,
    discover packet loss, partially loss and joinde packet and octett
    reverse too. And the most important sfrtp working fine over TCP or UDP
    (the first ~30% slower).

    Edfying result: The triple buffering more than 70% efficient than
    double buffering!!! The reason (maybe) the recv() or send() system call
    cost mouch resources.


    steve_schefter@hotmail.com wrote:
    > kzsolt@datanet.hu wrote:
    > > "3) Have the ..."
    > > But in that case not working, because the frameing always require
    > > buffer scroll (for escape sequence).

    >
    > This does not preclude avoiding a copy. You just have to handle
    > "frames" (or whatever you are calling your higher layer protocol
    > element) crossing UDP message boundaries.
    >
    > Or better yet, put some knowledge of the fact that you are
    > using UDP into the code and your "frame" will exist entirely
    > within one datagram (assuming it will fit). You then won't
    > have to have escape characters to mark your frame boundaries.
    >
    > > Other side our task is "using with
    > > standard calls", this mean we cannot go deeply to kernel, and we can
    > > migrate any time to x86solaris.

    >
    > Clearly I'm not following something here. Earlier you complained
    > about having to write the same algorithm in both kernel and user
    > space and I therefore noted that you don't need to get into user
    > space just to use sockets. Now you tell me that you want
    > portability to x86solaris which would mean that you need to be
    > doing it all in user space since there's no common DDI/DKI
    > in both Linux and Solaris. So how does the need to have the
    > algorithm in kernel space (and thus the duplication) come into
    > it?
    >
    > > This is maybe the only reason why UDP do not enable to
    > > read packet as octett only as packet.
    > > But "application" can (must) discover packet squence reverse from
    > > octett stream, so this is pain for us....

    >
    > We can only guess what was in the mind of the writers of IPv4,
    > but I'd be more inclinded to guess that you can only read UDP as
    > packet because it is a packet-based while you can read TCP as
    > bytes because it is byte-based (streaming). It still sounds to me
    > like you are trying to use UDP as a streaming protocol, which it
    > is not.
    >
    > > Other sides the UDP packet sequence problem littlebit mistificated. If
    > > you have complex IP network (maybe generate packet squence reverse)
    > > then you must use TCP instead of UDP. Otherwords in this kind of
    > > network UDP has more disadvantege then advantage.

    >
    > If you are relying upon the network to deliver UDP in order even for
    > the simplest network, then you have a serious design flaw. You
    > must always use the upper layer protocol to handle duplicated or
    > mis-ordered packets when using UDP, no matter what your
    > network looks like.
    >
    >
    > Regards,
    > Steve



+ Reply to Thread