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


T

Tom St Denis

bd said:
You can't. You'll have to use some non-standard extensions. Since you
didn't even tell us your OS, I can't give a pointer to a place where they
can help.

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
 
Ad

Advertisements

B

bd

bd said:
You can't. You'll have to use some non-standard extensions. Since you
didn't even tell us your OS, I can't give a pointer to a place where they
can help.

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.

These are not topical for comp.lang.c.
 
D

dbtid

bd said:
You can't. You'll have to use some non-standard extensions. Since you
didn't even tell us your OS, I can't give a pointer to a place where
they
can help.

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

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.
 
T

Thomas Matthews

Tom said:
dbtid said:
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.


Ok, listen up. I know it was OT, heck I said that in my original reply.

My comment was about the "oh which OS, how do I help? the agony!"

Is complete stupid B.S. All OSes I've seen such as QNX, Linux, BSD,
MacOS and Windows have fully functional Berkeley socket API
implementations included by default in most cases or with a socket lib
that is standard [wsock32.lib, libsocket.a, etc....]. Chances are the
guys OS does have a socket implementation.

If you're going to reply at least be correct and not randomly snipy.

Tom

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: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
 
T

Tom St Denis

Thomas said:
Tom said:
dbtid said:
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.



Ok, listen up. I know it was OT, heck I said that in my original reply.

My comment was about the "oh which OS, how do I help? the agony!"

Is complete stupid B.S. All OSes I've seen such as QNX, Linux, BSD,
MacOS and Windows have fully functional Berkeley socket API
implementations included by default in most cases or with a socket lib
that is standard [wsock32.lib, libsocket.a, etc....]. Chances are the
guys OS does have a socket implementation.

If you're going to reply at least be correct and not randomly snipy.

Tom

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.

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

HE HAS UDP SUPPORT IN HIS OS.

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
 
R

Richard Heathfield

dbtid /is/ correct.

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

HE HAS UDP SUPPORT IN HIS OS.

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.
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.

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.
 
Ad

Advertisements

D

dbtid

dbtid said:
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.

Ok, listen up. I know it was OT, heck I said that in my original reply.

My comment was about the "oh which OS, how do I help? the agony!"

Is complete stupid B.S. All OSes I've seen such as QNX, Linux, BSD,
MacOS and Windows have fully functional Berkeley socket API
implementations included by default in most cases or with a socket lib
that is standard [wsock32.lib, libsocket.a, etc....]. Chances are the
guys OS does have a socket implementation.

But they aren't part of C now, are they, which was the original thing
I was addressing, as well as the original responder.
If you're going to reply at least be correct and not randomly snipy.

I was, and you're the one who's being snippy.

Calm down, and cut back on the caffeine.
 
C

CBFalconer

Richard said:
Tom said:
.... snip ...

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.

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.

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.
 
R

Richard Heathfield

nobody said:
dbtid sez:

The minute you said "which OS" you lost the right to make that claim,
didn't you?

I can't find any reference in this thread to dbtid asking "which OS" the
OP is using.

Anyway, maybe you didn't notice, this is crossposted to
comp.protocols.tcp-ip, where St Denis's answer was very
much on the mark.

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.

<snip>
 
A

Abby

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.
 
T

Tom St Denis

Abby said:
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.

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
 
Ad

Advertisements

C

Chris Torek

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

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

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.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top