UDP vs TCP - TCP-IP

This is a discussion on UDP vs TCP - TCP-IP ; I tried udp's tcp's performance and saw nearly no difference... I mean transmitting performance is nearly same, even tcp is faster sometimes... Do u know a such a performance test result? (OS or network type is not important i just ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: UDP vs TCP

  1. UDP vs TCP

    I tried udp's tcp's performance and saw nearly no difference...
    I mean transmitting performance is nearly same, even tcp is faster
    sometimes...
    Do u know a such a performance test result? (OS or network type is not
    important
    i just tried between two pc using winsock2 & XP)
    (I did my test transmitting 1Gb of dummy data) (also while using UDP no
    packed
    has failed or been modified i guess... cuz of LAN i guess...)
    My purpose was to implement a comm type with udp which is a bit faster
    than tcp,
    with using only simple correction mechanism and without using
    congession preventive alg.s...
    but i am unsuccessful so far... I thought TCP's such operations are
    done in kernel level and
    thats why it is as fast as my own mechanism...?
    I am confused...


  2. Re: UDP vs TCP

    xenonysf wrote:

    > I tried udp's tcp's performance and saw nearly no difference...
    > I mean transmitting performance is nearly same, even tcp is faster
    > sometimes...
    > Do u know a such a performance test result? (OS or network type is not
    > important
    > i just tried between two pc using winsock2 & XP)
    > (I did my test transmitting 1Gb of dummy data) (also while using UDP no
    > packed
    > has failed or been modified i guess... cuz of LAN i guess...)
    > My purpose was to implement a comm type with udp which is a bit faster
    > than tcp,
    > with using only simple correction mechanism and without using
    > congession preventive alg.s...
    > but i am unsuccessful so far... I thought TCP's such operations are
    > done in kernel level and
    > thats why it is as fast as my own mechanism...?
    > I am confused...

    as far as I have understood the two protocols are meant for different
    purposes. it is not a question of speed, rather it is a question of
    usability.

    upd for data that may allow some degree of loss. for example voice over ip.
    tcp for data that may not allow for any type of loss what so ever. For
    example file transfers. that must be transmitted and also delivered without
    errors.

    I think there are other things regarding speed of transmissions, too:maximum
    transfer unit( MTU) comes into mind. Perhaps someone else can shed more
    light on this issue?thank's.

    so, regarding speed:think of what you will use it for, and then select the
    protocol. If you intend to stream som sort of time-critical data ( live
    audio, live video ), then use UDP ( losses may occur as udp is not
    connection oriented). if correct delivery is important to you ( for example
    if you want to trasfer a file, e.g. an mp3, for later listen, use TCP which
    is connection oriented and delivers what was sent.

  3. Re: UDP vs TCP

    "xenonysf" writes:

    >I tried udp's tcp's performance and saw nearly no difference...
    >I mean transmitting performance is nearly same, even tcp is faster
    >sometimes...


    That makes sense.

    The shared state that TCP uses can, if done right, cause TCP to run
    substantially faster than UDP. The TCP vs. UDP performance issues are
    usually a matter of what happens when there is loss and situations
    where TCP's loss recovery mechanism isn't desirable for the application.

    Craig

    Useful references:

    %A D.D. Clark
    %A V. Jacobson
    %A J. Romkey
    %A H. Salwen
    %T An Analysis of TCP Processing Overhead
    %J IEEE Communications
    %D June 1989
    %V 27
    %N 6
    %P 23-29

    %A V. Jacobson
    %T 4BSD Header Prediction
    %J ACM Computer Communication Review
    %D April 1990
    %V 20
    %N 1
    %P 13-15

    %A C. Partridge
    %A S. Pink
    %T A Faster UDP
    %J IEEE/ACM Trans. on Networking
    %V 1
    %N 4
    %D August 1993
    %X Describes optimizations to reduce UDP processing costs by over 30%.

  4. Re: UDP vs TCP


    xenonysf wrote:

    > I tried udp's tcp's performance and saw nearly no difference...
    > I mean transmitting performance is nearly same, even tcp is faster
    > sometimes...
    > Do u know a such a performance test result? (OS or network type is not
    > important
    > i just tried between two pc using winsock2 & XP)
    > (I did my test transmitting 1Gb of dummy data) (also while using UDP no
    > packed
    > has failed or been modified i guess... cuz of LAN i guess...)
    > My purpose was to implement a comm type with udp which is a bit faster
    > than tcp,
    > with using only simple correction mechanism and without using
    > congession preventive alg.s...
    > but i am unsuccessful so far... I thought TCP's such operations are
    > done in kernel level and
    > thats why it is as fast as my own mechanism...?
    > I am confused...


    You will not be able to make a better TCP than TCP. UDP is "faster"
    than TCP if and only if you don't need the overhead TCP adds. If you go
    and add that overhead to UDP yourself, you will have to do as good a
    job as TCP, which is not easy.

    DS


  5. Re: UDP vs TCP

    IMHO,
    UDP should outperform TCP.
    UDP header is 8 bytes while TCP's is minimum 20; TCP has to deal with
    these extra header fields for each packet.
    I remember that NFS (using UDP) can perform very well. If your
    applications communicate within LAN there won't be many lost or
    out-of-order packets.
    But if your UDP application needs any of TCP's function it'd be better
    to use TCP unless you can make it as good as TCP (which is not
    trivial), as others commented.



    xenonysf wrote:
    > I tried udp's tcp's performance and saw nearly no difference...
    > I mean transmitting performance is nearly same, even tcp is faster
    > sometimes...
    > Do u know a such a performance test result? (OS or network type is not
    > important
    > i just tried between two pc using winsock2 & XP)
    > (I did my test transmitting 1Gb of dummy data) (also while using UDP no
    > packed
    > has failed or been modified i guess... cuz of LAN i guess...)
    > My purpose was to implement a comm type with udp which is a bit faster
    > than tcp,
    > with using only simple correction mechanism and without using
    > congession preventive alg.s...
    > but i am unsuccessful so far... I thought TCP's such operations are
    > done in kernel level and
    > thats why it is as fast as my own mechanism...?
    > I am confused...



  6. Re: UDP vs TCP

    "jimyoo1@gmail.com" writes:

    >IMHO,
    >UDP should outperform TCP.
    >UDP header is 8 bytes while TCP's is minimum 20; TCP has to deal with
    >these extra header fields for each packet.


    That's a common misconception.

    Two broad issues on the receive side:

    * the UDP state lookup is more expensive than TCP's. For TCP you look up
    a full tuple, but in UDP, most servers are stateless and you
    have to match a wildcard... At the risk of oversimplifying, with TCP
    you can hash and either the
    state is in that hash bucket or it isn't. With UDP you must hash
    , but also dst addr, wildcard src port, dst port> and wildcard dst addr, wildcard src, dst port> and do all three lookups
    to be sure of finding the right state for the inbound packet.

    This effectively swamps the field processing.

    * many of the TCP fields are relevant only in exceptional situations.
    As Jacobson showed, you can basically do a fancy mask against
    what you expect to see in several of the TCP header fields -- 90% of the
    time you'll get what you expected and so you can ignore those fields.
    So counting fields doesn't represent cost...

    Send side is a more complex comparison (where, if my memory serves,
    UDP wins, but not by much -- unless you've got a bad memory architecture,
    in which case UDP can win big).

    Craig

  7. Re: UDP vs TCP

    In article ,
    Craig Partridge wrote:

    >>UDP should outperform TCP.
    >>UDP header is 8 bytes while TCP's is minimum 20; TCP has to deal with
    >>these extra header fields for each packet.

    >
    >That's a common misconception.


    It's nice to no longer hear the older misconception that UDP and TCP
    must be slower than raw Ethernet.


    >Two broad issues on the receive side:
    >
    >* the UDP state lookup is more expensive than TCP's.


    > This effectively swamps the field processing.
    >
    >* many of the TCP fields are relevant only in exceptional situations.
    > As Jacobson showed, you can basically do a fancy mask against


    As much fun as this is, I doubt that it is relevant in real life
    today or to the real problems of the person who started this thread.
    The start of this thread contained the surprising statement that "OS
    or network type is not important."

    With hosts turning lots of instructions per nanosecond, they have
    to be moving a lot of UDP packets or TCP segments per second to
    care about CPU cycles spent crunching TCP or UDP headers. Even
    then, they're likely to spend orders of magnitude more time waiting for
    memory bandwidth for user data than computing on a dozen values
    in each TCP or UDP header.
    Let's not forget the TCP or UDP checksum (if not done in hardware or fly-by
    firmware) that is likely to involve
    10 or 100 times as many cycles as the fewer than 200 cycles per TCP
    segment that I vaguely recall that Van Jacobson report 10 or 12 years
    ago. Of course, the checksum CPU cycle costs are likely to be overwhemed
    by memory bandwidth costs.

    Then there are the costs of whatever the application is doing. I think
    synthetic benchmarks are great wonderful (as anyone who recalls my old
    ttcp bragging knows), but they're often irrelevant except for marketing.


    >Send side is a more complex comparison (where, if my memory serves,
    >UDP wins, but not by much -- unless you've got a bad memory architecture,
    >in which case UDP can win big).


    Carefully chosen, sufficently bad (for the target application) designs
    can change almost any arbitrarily chosen answer from wrong to right.


    Vernon Schryver vjs@rhyolite.com

  8. Re: UDP vs TCP

    Thank u very much for every answer...
    Since i am a newbie of such programming and
    networking, i asked this question...
    But nothing goes waste which you have done, because
    you learn many new things even if it is a failure...
    that was the only benefit that i gained from this...

    but i was able to implement a UDP listener, and/or
    data dispatcher to different object buffers while these
    objects are used to communicate with clients on server side.
    I mean i have build up a structure like TCP's connected
    structure.

    I dont know there is a possibility to simulate TCP's accept()
    style accepting for UDP or not... (also UDP hasnt got a connect() ) ?
    Is possible such a strategy with existing socket functions?
    (actually i have searched for such strategy but coulndt find, and
    i dont know what does listen() mean on a UDP socket? )

    Vernon Schryver wrote:
    > In article ,
    > Craig Partridge wrote:
    >
    > >>UDP should outperform TCP.
    > >>UDP header is 8 bytes while TCP's is minimum 20; TCP has to deal with
    > >>these extra header fields for each packet.

    > >
    > >That's a common misconception.

    >
    > It's nice to no longer hear the older misconception that UDP and TCP
    > must be slower than raw Ethernet.
    >
    >
    > >Two broad issues on the receive side:
    > >
    > >* the UDP state lookup is more expensive than TCP's.

    >
    > > This effectively swamps the field processing.
    > >
    > >* many of the TCP fields are relevant only in exceptional situations.
    > > As Jacobson showed, you can basically do a fancy mask against

    >
    > As much fun as this is, I doubt that it is relevant in real life
    > today or to the real problems of the person who started this thread.
    > The start of this thread contained the surprising statement that "OS
    > or network type is not important."
    >
    > With hosts turning lots of instructions per nanosecond, they have
    > to be moving a lot of UDP packets or TCP segments per second to
    > care about CPU cycles spent crunching TCP or UDP headers. Even
    > then, they're likely to spend orders of magnitude more time waiting for
    > memory bandwidth for user data than computing on a dozen values
    > in each TCP or UDP header.
    > Let's not forget the TCP or UDP checksum (if not done in hardware or fly-by
    > firmware) that is likely to involve
    > 10 or 100 times as many cycles as the fewer than 200 cycles per TCP
    > segment that I vaguely recall that Van Jacobson report 10 or 12 years
    > ago. Of course, the checksum CPU cycle costs are likely to be overwhemed
    > by memory bandwidth costs.
    >
    > Then there are the costs of whatever the application is doing. I think
    > synthetic benchmarks are great wonderful (as anyone who recalls my old
    > ttcp bragging knows), but they're often irrelevant except for marketing.
    >
    >
    > >Send side is a more complex comparison (where, if my memory serves,
    > >UDP wins, but not by much -- unless you've got a bad memory architecture,
    > >in which case UDP can win big).

    >
    > Carefully chosen, sufficently bad (for the target application) designs
    > can change almost any arbitrarily chosen answer from wrong to right.
    >
    >
    > Vernon Schryver vjs@rhyolite.com



  9. Re: UDP vs TCP

    "xenonysf" writes:
    > I dont know there is a possibility to simulate TCP's accept()
    > style accepting for UDP or not...


    With BSD sockets, you'll be hard-pressed to get the local binding
    behavior right.

    > (also UDP hasnt got a connect() ) ?


    Yes, it does. It just does something that's meaningful for UDP.

    > Is possible such a strategy with existing socket functions?
    > (actually i have searched for such strategy but coulndt find, and
    > i dont know what does listen() mean on a UDP socket? )


    Listen() doesn't work on UDP because there's no such concept there.

    If you really want TCP, then use that. Or, if you need datagram
    orientation, try SCTP instead.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  10. Re: UDP vs TCP


    James Carlson wrote:
    > "xenonysf" writes:
    > > I dont know there is a possibility to simulate TCP's accept()
    > > style accepting for UDP or not...

    >
    > With BSD sockets, you'll be hard-pressed to get the local binding
    > behavior right.


    i am using Winsock and here is the result of bind() or accept() on a

    socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

    bind() or accept() gives following error;

    WSAEPROTONOSUPPORT
    10043
    Protocol not supported.

    > > (also UDP hasnt got a connect() ) ?

    >
    > Yes, it does. It just does something that's meaningful for UDP.


    So i think i even couldnt reach this point....

    > > Is possible such a strategy with existing socket functions?
    > > (actually i have searched for such strategy but coulndt find, and
    > > i dont know what does listen() mean on a UDP socket? )

    >
    > Listen() doesn't work on UDP because there's no such concept there.
    >
    > If you really want TCP, then use that. Or, if you need datagram
    > orientation, try SCTP instead.
    >
    > --
    > James Carlson, KISS Network
    > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677



  11. Re: UDP vs TCP

    "xenonysf" writes:
    > James Carlson wrote:
    > > "xenonysf" writes:
    > > > I dont know there is a possibility to simulate TCP's accept()
    > > > style accepting for UDP or not...

    > >
    > > With BSD sockets, you'll be hard-pressed to get the local binding
    > > behavior right.

    >
    > i am using Winsock and here is the result of bind() or accept() on a
    >
    > socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);


    I don't think you want "IPPROTO_UDP" there, though that still ought to
    work.

    > bind() or accept() gives following error;


    There's no "accept()" for UDP.

    > WSAEPROTONOSUPPORT
    > 10043
    > Protocol not supported.


    Something's wrong with the code you're using if you get that out of
    bind(). Bind() should work on UDP.

    At a guess, the sockaddr_in structure wasn't initialized or sin_family
    wasn't set. (But I'm not a Windows user; perhaps you need Windows-
    specific help.)

    > > > (also UDP hasnt got a connect() ) ?

    > >
    > > Yes, it does. It just does something that's meaningful for UDP.

    >
    > So i think i even couldnt reach this point....


    I _strongly_ recommend finding a good textbook that describes the
    TCP/IP protocol suite and how to write networking applications. The
    W. Richard Stevens books are excellent.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  12. Re: UDP vs TCP


    "James Carlson" wrote in message
    news:xoavfyewf2i3.fsf@sun.com...
    > "xenonysf" writes:
    >> James Carlson wrote:
    >> > "xenonysf" writes:
    >> > > I dont know there is a possibility to simulate TCP's accept()
    >> > > style accepting for UDP or not...
    >> >
    >> > With BSD sockets, you'll be hard-pressed to get the local binding
    >> > behavior right.

    >>
    >> i am using Winsock and here is the result of bind() or accept() on a
    >>
    >> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

    >
    > I don't think you want "IPPROTO_UDP" there, though that still ought to
    > work.
    >
    >> bind() or accept() gives following error;

    >
    > There's no "accept()" for UDP.
    >
    >> WSAEPROTONOSUPPORT
    >> 10043
    >> Protocol not supported.

    >
    > Something's wrong with the code you're using if you get that out of
    > bind(). Bind() should work on UDP.
    >
    > At a guess, the sockaddr_in structure wasn't initialized or sin_family
    > wasn't set. (But I'm not a Windows user; perhaps you need Windows-
    > specific help.)
    >


    Agree, bind() should work fine. Below is part of some experimental C++ UDP
    server code that works just fine under Windows. I'm no expert on TCP/IP but
    since UDP is connection-less the only meaningful thing a server can do is
    wait for packets to arrive and then somehow dispatch them. The TCP-style
    listen/accept scheme doesn't really apply so I usually do

    socket()
    bind()
    loop
    select()
    recvfrom()

    I think you may be able to avoid select() and use recvfrom in blocking mode
    but I'm not sure if I ever got that to work right under Windows.

    Hope that helps,
    Andrew




    WORD versionRequested = MAKEWORD( 2, 2 );
    WSADATA wsaData;
    TelecamServer srv;
    int err = WSAStartup( versionRequested, &wsaData );
    if ( err != 0 )
    {
    printf("couldn't startup\n");
    return -1;
    }

    // create a UDP socket
    SOCKET sl = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    if (sl == INVALID_SOCKET)
    {
    printf("couldn't create udp socket\n");
    return -1;
    }

    // bind socket to port 50010
    sockaddr_in sa;
    memset(&sa, 0, sizeof sa);
    sa.sin_family = AF_INET;
    sa.sin_port = htons(50010);
    if (!bind(sl, (sockaddr *)&sa, sizeof sa))
    {
    // receive datagrams on the socket get sender's address
    sockaddr_in senderAddr;
    memset(&senderAddr, 0, sizeof senderAddr);
    int bs, br, senderAddrLen = sizeof senderAddr;
    timeval sto;
    sto.tv_sec = 1;
    sto.tv_usec = 0;
    fd_set fds;
    char bar[]="|/-\\";
    int bp=0;
    while (1)
    {
    FD_ZERO(&fds);
    FD_SET(sl, &fds);
    if (select(0, &fds, 0, 0, &sto) == 0)
    {
    // nothing to read
    printf("\r%c", bar[bp++ & 0x3]);
    fflush(stdout);
    // handle timeouts appropriately
    }
    else
    {
    if ((br = recvfrom(sl, frameBuf, sizeof frameBuf, 0, (sockaddr
    *)&senderAddr, &senderAddrLen)) > 0)
    {
    printf("received %d bytes from %x:%d\n", br,
    senderAddr.sin_addr.S_un.S_addr, senderAddr.sin_port);




  13. Re: UDP vs TCP


    James Carlson wrote:
    > "xenonysf" writes:
    > > James Carlson wrote:
    > > > "xenonysf" writes:
    > > > > I dont know there is a possibility to simulate TCP's accept()
    > > > > style accepting for UDP or not...
    > > >
    > > > With BSD sockets, you'll be hard-pressed to get the local binding
    > > > behavior right.

    > >
    > > i am using Winsock and here is the result of bind() or accept() on a
    > >
    > > socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

    >
    > I don't think you want "IPPROTO_UDP" there, though that still ought to
    > work.


    Why? Yes i want to use UDP? Isnt that the way?

    > > bind() or accept() gives following error;

    >
    > There's no "accept()" for UDP.


    This is what i needed actually. Thats why i implemented a function like
    accept()

    > > WSAEPROTONOSUPPORT
    > > 10043
    > > Protocol not supported.

    >
    > Something's wrong with the code you're using if you get that out of
    > bind(). Bind() should work on UDP.
    >
    > At a guess, the sockaddr_in structure wasn't initialized or sin_family
    > wasn't set. (But I'm not a Windows user; perhaps you need Windows-
    > specific help.)
    >
    > > > > (also UDP hasnt got a connect() ) ?
    > > >
    > > > Yes, it does. It just does something that's meaningful for UDP.

    > >
    > > So i think i even couldnt reach this point....

    >
    > I _strongly_ recommend finding a good textbook that describes the
    > TCP/IP protocol suite and how to write networking applications. The
    > W. Richard Stevens books are excellent.


    Thank u very much, i ll keep in mind

    > --
    > James Carlson, KISS Network
    > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677



  14. Re: UDP vs TCP

    Yes i know this, than u very much...
    But how do u dispatch data into different buffers?

    andrew queisser wrote:
    > "James Carlson" wrote in message
    > news:xoavfyewf2i3.fsf@sun.com...
    > > "xenonysf" writes:
    > >> James Carlson wrote:
    > >> > "xenonysf" writes:
    > >> > > I dont know there is a possibility to simulate TCP's accept()
    > >> > > style accepting for UDP or not...
    > >> >
    > >> > With BSD sockets, you'll be hard-pressed to get the local binding
    > >> > behavior right.
    > >>
    > >> i am using Winsock and here is the result of bind() or accept() on a
    > >>
    > >> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

    > >
    > > I don't think you want "IPPROTO_UDP" there, though that still ought to
    > > work.
    > >
    > >> bind() or accept() gives following error;

    > >
    > > There's no "accept()" for UDP.
    > >
    > >> WSAEPROTONOSUPPORT
    > >> 10043
    > >> Protocol not supported.

    > >
    > > Something's wrong with the code you're using if you get that out of
    > > bind(). Bind() should work on UDP.
    > >
    > > At a guess, the sockaddr_in structure wasn't initialized or sin_family
    > > wasn't set. (But I'm not a Windows user; perhaps you need Windows-
    > > specific help.)
    > >

    >
    > Agree, bind() should work fine. Below is part of some experimental C++ UDP
    > server code that works just fine under Windows. I'm no expert on TCP/IP but
    > since UDP is connection-less the only meaningful thing a server can do is
    > wait for packets to arrive and then somehow dispatch them. The TCP-style
    > listen/accept scheme doesn't really apply so I usually do
    >
    > socket()
    > bind()
    > loop
    > select()
    > recvfrom()
    >
    > I think you may be able to avoid select() and use recvfrom in blocking mode
    > but I'm not sure if I ever got that to work right under Windows.
    >
    > Hope that helps,
    > Andrew
    >
    >
    >
    >
    > WORD versionRequested = MAKEWORD( 2, 2 );
    > WSADATA wsaData;
    > TelecamServer srv;
    > int err = WSAStartup( versionRequested, &wsaData );
    > if ( err != 0 )
    > {
    > printf("couldn't startup\n");
    > return -1;
    > }
    >
    > // create a UDP socket
    > SOCKET sl = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    > if (sl == INVALID_SOCKET)
    > {
    > printf("couldn't create udp socket\n");
    > return -1;
    > }
    >
    > // bind socket to port 50010
    > sockaddr_in sa;
    > memset(&sa, 0, sizeof sa);
    > sa.sin_family = AF_INET;
    > sa.sin_port = htons(50010);
    > if (!bind(sl, (sockaddr *)&sa, sizeof sa))
    > {
    > // receive datagrams on the socket get sender's address
    > sockaddr_in senderAddr;
    > memset(&senderAddr, 0, sizeof senderAddr);
    > int bs, br, senderAddrLen = sizeof senderAddr;
    > timeval sto;
    > sto.tv_sec = 1;
    > sto.tv_usec = 0;
    > fd_set fds;
    > char bar[]="|/-\\";
    > int bp=0;
    > while (1)
    > {
    > FD_ZERO(&fds);
    > FD_SET(sl, &fds);
    > if (select(0, &fds, 0, 0, &sto) == 0)
    > {
    > // nothing to read
    > printf("\r%c", bar[bp++ & 0x3]);
    > fflush(stdout);
    > // handle timeouts appropriately
    > }
    > else
    > {
    > if ((br = recvfrom(sl, frameBuf, sizeof frameBuf, 0, (sockaddr
    > *)&senderAddr, &senderAddrLen)) > 0)
    > {
    > printf("received %d bytes from %x:%d\n", br,
    > senderAddr.sin_addr.S_un.S_addr, senderAddr.sin_port);



  15. Re: UDP vs TCP

    "xenonysf" writes:
    > > I don't think you want "IPPROTO_UDP" there, though that still ought to
    > > work.

    >
    > Why? Yes i want to use UDP? Isnt that the way?


    It's just asking for trouble. The common way to do this is:

    socket(AF_INET, SOCK_DGRAM, 0);

    .... that is, 0 rather than IPPROTO_UDP.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread