"connecting" UDP similar to how TCP does it ?

[R.Wieser]

Hello all,

I would like to know if its possible to have Windows "accept" an UDP
connection in the same way it accepts a TCP one: the receiver creating a new
socket and return that to the caller to use for further communication.

I've already written such a mechanism (which works well enough), but am
wondering if its already build in ... (don't think so, but I do not know
everything :-) )

Regards,
Rudy Wieser

[Charlie Gibbs]

Post by R.Wieser
Hello all,
I would like to know if its possible to have Windows "accept" an UDP
connection in the same way it accepts a TCP one: the receiver creating a new
socket and return that to the caller to use for further communication.

Since UDP is a connectionless protocol, the concept of accepting
a UDP connection is meaningless. To quote the accept() man page:

The accept() system call is used with connection-based socket types
(SOCK_STREAM, SOCK_SEQPACKET).

Post by R.Wieser
I've already written such a mechanism (which works well enough), but am
wondering if its already build in ... (don't think so, but I do not know
everything :-) )

If you've written a wrapper that makes usage more consistent for you,
great. But there's nothing like that built in. In fact, since each
incoming UDP datagram contains the IP address of its originator, you
can have one socket handle as many UDP connections as you want.

https://stackoverflow.com/questions/14902402/why-there-is-no-accept-for-udp

[R.Wieser]

Charlie,

Post by Charlie Gibbs
Since UDP is a connectionless protocol, the concept of
accepting a UDP connection is meaningless.

:-) I didn't ask for the exact same, just for the mechanism of handing-off
the "connection" to another port. Ofcourse, if it than also binds that UDP
port to the requesters IP and port you don't have to worry about (other IPs)
chatter anymore ...

Post by Charlie Gibbs
If you've written a wrapper that makes usage more consistent for
you, great. But there's nothing like that built in.

Yep, that was the question.

Post by Charlie Gibbs
In fact, since each incoming UDP datagram contains the IP address
of its originator, you can have one socket handle as many UDP
connections as you want.

What are those "connections" you are speaking of there ? :-p

But ask yourself: Why doesn't a TCP socket allow multiple connections on a
single port too ? Why does an "accept" hand off the connection to a
different port ?

Answer that and you most likely have the reason why I want-and-do the same
with UDP. :-)

Regards,
Rudy Wieser

[Charlie Gibbs]

Post by R.Wieser

Post by Charlie Gibbs
In fact, since each incoming UDP datagram contains the IP address
of its originator, you can have one socket handle as many UDP
connections as you want.

What are those "connections" you are speaking of there ? :-p

Oops. Bad choice of words. See below.

Post by R.Wieser
But ask yourself: Why doesn't a TCP socket allow multiple connections on a
single port too ?
Why does an "accept" hand off the connection to a different port ?

A single TCP socket might not allow multiple connections, but TCP itself
does allow multiple connections to the same port number. You need a
separate socket for each connection, and accept() gives you those sockets.
If you program it correctly, you can accept multiple incoming connections
on the same port number and keep them all separate. Been there, done that.

Post by R.Wieser
Answer that and you most likely have the reason why I want-and-do the same
with UDP. :-)

I can guess: consistency. More power to you. In fact, I've read that
you can even use connect(), recv(), and send() on a datagram socket -
although I've never seen the need myself.

On the other hand, as I mentioned above (if somewhat poorly), if you're
working solely with UDP, there's nothing stopping you from receiving
datagrams from multiple sources with a single socket; each datagram
contains the IP address it came from, so you can sort them out.

As long as you follow the rules, either approach works. It all comes
down to personal choice.

There's an excellent reference which I still look at from time to time:
Beej's Guide to Network Programming (https://beej.us.guide/bgnet/).
It's very well written, and a treasure trove of information.

[R.Wieser]

Charlie,

Post by Charlie Gibbs

Post by R.Wieser
What are those "connections" you are speaking of there ? :-p

Oops. Bad choice of words. See below.

Don't worry, I understood what you wanted to say. Just couldn't help
myself teasing you a bit.

Post by Charlie Gibbs
A single TCP socket might not allow multiple connections, but TCP
itself does allow multiple connections to the same port number. You
need a separate socket for each connection, and accept() gives you
those sockets.

I'm going to assume you are calling that accept() on a listening socket. If
so, than take a peek at the socket(s) you get from that accept(). Each one
has a fully different port number (always 1024 or above) than the listening
socket you called accept() on. So, no multiple connections on a single TCP
port.

Post by Charlie Gibbs
If you program it correctly, you can accept multiple incoming
connections on the same port number and keep them all separate.

Which is exactly why I'm emulating that same mechanism for my UDP
"connections" :-)

Post by Charlie Gibbs

Post by R.Wieser
Answer that and you most likely have the reason why I want-and-do the
same with UDP. :-)

I can guess: consistency.

Ease of handling actually. That way I do not need to play switchboard for
all the UDP packets that come in and need to be handled by different
sub-programs (as well as keeping the sub-programs states).

Post by Charlie Gibbs
In fact, I've read that you can even use connect(), recv(), and send() on
a
datagram socket - although I've never seen the need myself.

Its what I also mentioned to another guy in this thread: By using connect()
on an UDP socket you get multiple goodies for free:
1) Only packets from the "connected" IP and port will reach you. Packets
from other 'puters and/or ports are silently discarded/ignored.
2) You do not have to remember the IP and port of the other 'puter, as they
are stored in the socket (which is why you can use send() and recv() ).

Post by Charlie Gibbs
On the other hand, as I mentioned above (if somewhat poorly), if
you're working solely with UDP, there's nothing stopping you from
receiving datagrams from multiple sources with a single socket;

But thats, in this case and for simplicities sake, exactly what I /don't/
want. :-)

Post by Charlie Gibbs
There's an excellent reference which I still look at from time to
time: Beej's Guide to Network Programming
(https://beej.us.guide/bgnet/).
It's very well written, and a treasure trove of information.

Thanks for that link. Though you might have made a typo, as I had to
replace "us.guide" with "us/guide" (google to the rescue! :-) ) ... Either
that, or you need to update your link.

Regards,
Rudy Wieser

[Charlie Gibbs]

Post by R.Wieser

Post by Charlie Gibbs
There's an excellent reference which I still look at from time to
time: Beej's Guide to Network Programming
(https://beej.us.guide/bgnet/).
It's very well written, and a treasure trove of information.

Thanks for that link. Though you might have made a typo, as I had to
replace "us.guide" with "us/guide" (google to the rescue! :-) ) ...
Either that, or you need to update your link.

You're right, it's a typo. That's what I get for looking it up on
a different machine. (In my case, it's DuckDuckGo to the rescue -
my machine is a Google-free zone.)

[Kaz Kylheku]

Post by R.Wieser
Hello all,
I would like to know if its possible to have Windows "accept" an UDP
connection in the same way it accepts a TCP one: the receiver creating a new
socket and return that to the caller to use for further communication.
I've already written such a mechanism (which works well enough), but am
wondering if its already build in ... (don't think so, but I do not know
everything :-) )

There isn't any such thing in the Unix-derived sockets API.

Like you, I've also developed a purely library based implementation
of the concept of accepting a UDP socket.

It's probably entirely different from what you have, but maybe not.

This is implemented in the TXR Lisp language as "Datagram Socket
Streams".

https://www.nongnu.org/txr/txr-manpage.html#N-01F91F35

The idea is that a single UDP datagram constitutes a stream. The
server calls sock-accept on the "listening" UDP socket. The operation
returns a new socket when a request datagram arrives. Read operations on
that new socket will successively retrieve bytes from that one and only
UDP datagram. The socket is associated with the address of the client,
and has a reference to the original UDP server socket, which allows
write operations on the accepted socket to send back a datagram
reply to the original client.

There is a test case in the TXR Lisp test suite which exercises
it:

http://www.kylheku.com/cgit/txr/tree/tests/014/socket-basic.tl

There is a top-level loop in this test case which iterates the
socktype variable over the values sock-dgram sock-stream.
So basically the entire test case is repeated twice: once with
datagram sockets and once with stream sockets. (In the AF_INET
address family; i.e. UDP and TCP).

Obvoiusly, "one datagram is one stream" has limitations. Clients have to
send their entire request at once; we cannot have a back and forth chat
over this "connection". It's essentially half duplex. If we have a new
request, we make a new connection. The unreliability of UDP isn't
addressed either.

But what this enables you to do is write a UDP-based communication
solution (which doesn't mind these restrictions) and then make it work
over TCP also with no code changes.

[R.Wieser]

Kaz,

Post by Kaz Kylheku
It's probably entirely different from what you have, but maybe not.

...

Post by Kaz Kylheku
The idea is that a single UDP datagram constitutes a stream.

In my case I have the need to regard a number of UDP datagrams as being a
single stream. Its just that the "handing of to another port" approach
makes the whole stream rather easy to handle - each one (on the Windows
side) can than be handled by a seperate thread.

That, and binding the port to the senders IP and port gives an easy way to
filter out all kinds of (other IPs and ports) chatter, keeping the "stream"
clean.

Thanks for the info though.

Regards,
Rudy Wieser