Re: How to format/send/receive UDP packet in C?

Discussion in 'C Programming' started by Tom St Denis, Jun 24, 2003.

  1. Tom St Denis

    Tom St Denis Guest

    I don't think you're reply was at all accurate. Most OSes support the
    Berkeley socket API [e.g. socket(), bind(), connect(), ....]. Heck even
    windows supports it.

    That being said the OP really should invest in some google time. There
    are tons of demos of TCP/UDP routines out there.

    Tom St Denis, Jun 24, 2003
    1. Advertisements

  2. Tom St Denis

    bd Guest

    These are not topical for comp.lang.c.
    bd, Jun 24, 2003
    1. Advertisements

  3. Tom St Denis

    dbtid Guest

    His reply certainly was accurate from the C Standard.

    Regulars to "comp.lang.c" know that things like UDP, TCP/IP, OS's,
    etc, are not topical because they are outside of the Standard. His reply
    was certainly accurate.

    The OP was OT, albeit he didn't know it.

    His comment that the C language does not support things like UDP is
    accurate; those things are part of the operating system and the libraries
    that come with them. They are NOT part of C.
    dbtid, Jun 24, 2003
  4. What about embedded operating systems like Nucleus Plus and Vertex?
    Many embeded operating systems, especially the home grown ones, don't
    have the room for UDP, TCP/IP stuff. This network support layer
    is only valid for platforms that provide that functionality.

    Thomas Matthews

    C Faq:
    alt.comp.lang.learn.c-c++ faq:
    Thomas Matthews, Jun 24, 2003
  5. Tom St Denis

    Tom St Denis Guest

    Chances are if he was asking about UDP... guess what... just guess. Oh
    common, put your damn college edumication to use....


    Chances are if he has UDP support... guess what... just guess. It is
    probably based on Berkeley sockets API.

    Oh my god are you people this anal. Not only did you guys not answer
    his question [as to be expected from clc] but you were WRONG while
    doing it.

    Tom St Denis, Jun 24, 2003
  6. dbtid /is/ correct.

    Take your own medicine, please.
    That is an unwarranted conclusion. Whilst he /probably/ has UDP support,
    he might not. Someone might well ask about UDP despite their OS or
    implementation not providing support for it. This is analogous to
    someone asking how to do fork() in Visual C++, which is a question that
    I've come across several times.
    Actually, they were correct to object. Topical questions are generally
    answered correctly in clc, and without the "randomly snipy" behaviour
    which you berate when you perceive it (rightly or wrongly) in others but
    in which you seem only too willing to indulge yourself. I see nothing
    wrong with the answers to which you are objecting.
    Richard Heathfield, Jun 24, 2003
  7. Tom St Denis

    dbtid Guest

    But they aren't part of C now, are they, which was the original thing
    I was addressing, as well as the original responder.
    I was, and you're the one who's being snippy.

    Calm down, and cut back on the caffeine.
    dbtid, Jun 24, 2003
  8. Tom St Denis

    CBFalconer Guest

    In fact answers to OT questions are automatically to be considered
    suspect. Meanwhile our resident raging Ottawa Teenager shows no
    signs of maturation nor of requiring removal from my PLONK file.
    Note the dual interpretation of OT possible.
    CBFalconer, Jun 25, 2003
  9. I can't find any reference in this thread to dbtid asking "which OS" the
    OP is using.

    That's fantastic, brilliant, and possibly even terrific, but it doesn't
    make Mr St Denis's answer any less off the mark here in comp.lang.c.

    Richard Heathfield, Jun 25, 2003
  10. Tom St Denis

    Abby Guest

    Hi all,

    Thanks for your replies. I'm using Windows XP to code. Anyway, I
    downloaded the cygwin so that it has the same environment as in Linux.
    I'm intend to use my code in both windows and linux.

    The big question I have in mind right now is about how to receive
    the packet. I've seen the client/server code, but I haven't seen the
    code which send out packet to server, then receive the response back
    from that server.
    The code I got will send out packet, then the server receive packet
    and do something .. (like showing that packet on the screen). I don't
    need that ... 'cos after the server get the packet I sent, it will
    send me back some data, and I need to find a way how to display that
    data to my screen. If any of you have any clue, please let me know.
    I'm just a beginner in network programming, so please forgive me if my
    question seems to be stupid to you.

    Thank to you all.

    Abby, Jun 25, 2003
  11. Tom St Denis

    Tom St Denis Guest

    You have make up a socket() for a given address and port [using
    SOCK_DGRAM not SOCK_STREAM], then bind() it and if I'm not mistaken
    simply recvfrom() to read [note: recvfrom() is blocking in most
    cases...] to read incomming packets. The recvfrom() will also fill in a
    sockaddr_in structure so you know where the packet came from.

    There is no connect()/accept() for UDP since is is connection-less.

    Tom St Denis, Jun 26, 2003
  12. Tom St Denis

    Chris Torek Guest

    This neatly illustrates one of the problems with answering off-topic

    While UDP *is* connectionless, BSD-based systems *do* allow connect()
    calls. "Connecting" a UDP socket to a particular foreign address
    allows future data transmission without re-specifying the same
    remote address every time. This is not only a convenience, it also
    allows -- and this ties in to comp.lang.c at least -- one to use
    ordinary write operations on the descriptor afterward. Combine
    this with the POSIX fdopen() call, and you get an ordinary C stream
    on which regular fwrite() and fprintf() operations work.

    Incidentally, I have argued in the past (and still believe) that
    having separate bind(), connect(), and listen() calls is a mistake.
    There should be a single call that combines all three operations,
    with the operands being optional where irrelevant. This would
    completely eliminate the need for the SO_REUSEADDR socket option.
    If you want to run a generic server, supply port and listen-queue-length;
    if you want to run a generic client, supply server address and
    port; if you want to run a specialty application (as, e.g., FTP
    does for its data sockets), supply both client and server ports
    and/or addresses as required.
    Chris Torek, Jun 26, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.