While playing around with libuv I noticed we don't have support for 'connecting' a UDP socket, nor for sending data to such a socket.
I'd like to have it so I thought about a straightforward API, but Bert raised some interesting questions on IRC, so lets discuss :-)
My proposal:
uv_udp_connect / uv_udp_connect6 -> connects the udp socket. AFAIK this doesn't block on UDP, so it would just take the handle and sockaddr_in or sockaddr_in6 as arguments.
For sending I have 2 options:
uv_udp_send becomes uv_udp_sendto.
a new uv_udp_send which doesn't take the remote address as an argument
or
allow passing NULL as the remote address to uv_udp_send
Bert suggested that conencted UDP sockets look like streams so maybe we should consider them so.
IMHO that's a bit of a stretch. At least at the libuv level. If we would do that, what about the not connected UDP sockets? What would uv_shutdown do? If at a higher level someone wants to treat connected UDP sockets as streams that's fine though.
> While playing around with libuv I noticed we don't have support for
> 'connecting' a UDP socket, nor for sending data to such a socket.
> I'd like to have it so I thought about a straightforward API, but Bert
> raised some interesting questions on IRC, so lets discuss :-)
> My proposal:
> uv_udp_connect / uv_udp_connect6 -> connects the udp socket. AFAIK this
> doesn't block on UDP, so it would just take the handle and sockaddr_in or
> sockaddr_in6 as arguments.
> For sending I have 2 options:
> uv_udp_send becomes uv_udp_sendto.
> a new uv_udp_send which doesn't take the remote address as an argument
> or
> allow passing NULL as the remote address to uv_udp_send
It's kind of a pointless exercise in my opinion. It's only marginally
more involved for the libuv user to remember the address he wants to
send data to.
> Bert suggested that conencted UDP sockets look like streams so maybe we
> should consider them so.
> IMHO that's a bit of a stretch. At least at the libuv level. If we would do
> that, what about the not connected UDP sockets? What would uv_shutdown do?
> If at a higher level someone wants to treat connected UDP sockets as streams
> that's fine though.
I don't see that working. Streams are many things that UDP is not:
ordered, reliable, chunk size agnostic.
Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 9:13 AM, Sa l Ibarra Corretg <sag...@gmail.com> wrote:
>> Hi,
>> While playing around with libuv I noticed we don't have support for
>> 'connecting' a UDP socket, nor for sending data to such a socket.
>> I'd like to have it so I thought about a straightforward API, but Bert
>> raised some interesting questions on IRC, so lets discuss :-)
>> My proposal:
>> uv_udp_connect / uv_udp_connect6 -> connects the udp socket. AFAIK this
>> doesn't block on UDP, so it would just take the handle and sockaddr_in or
>> sockaddr_in6 as arguments.
>> For sending I have 2 options:
>> uv_udp_send becomes uv_udp_sendto.
>> a new uv_udp_send which doesn't take the remote address as an argument
>> or
>> allow passing NULL as the remote address to uv_udp_send
> It's kind of a pointless exercise in my opinion. It's only marginally
> more involved for the libuv user to remember the address he wants to
> send data to.
I guess... btw, what would happen if I send data to another destination to which I connected to?
>> Bert suggested that conencted UDP sockets look like streams so maybe we
>> should consider them so.
>> IMHO that's a bit of a stretch. At least at the libuv level. If we would do
>> that, what about the not connected UDP sockets? What would uv_shutdown do?
>> If at a higher level someone wants to treat connected UDP sockets as streams
>> that's fine though.
> I don't see that working. Streams are many things that UDP is not:
> ordered, reliable, chunk size agnostic.
Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 3:44 PM, Saúl Ibarra Corretgé<sag...@gmail.com> wrote:
>> I guess... btw, what would happen if I send data to another destination to
>> which I connected to?
> That particular datagram gets sent to the address you specified, the
> default target address remains unchanged.
Cool. Then I'll just make a pull request for uv_udp_connect.
Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 4:15 PM, Saúl Ibarra Corretgé<sag...@gmail.com> wrote:
>> Cool. Then I'll just make a pull request for uv_udp_connect.
> Maybe I should have stressed more that I don't see the need for it. :-)
> In general, I only want to see code in libuv that solves Real
> Problems. uv_udp_connect() is not that, it's just a convenience thing.
Oh, I thought you said that about the uv_udp_send / sendto thing. Well, if I want to send UDP data to a given destination and read back from it, why should I receive data from others? I don't have a requirement for this at the moment, so I was just wondering if it was intentionally missing or just not implemented because there are other priorities.
If you don't want it in, then that's fine with me for now. I'll bug you again when I have a strong need for it ;-)
On Fri, Sep 21, 2012 at 5:03 PM, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> Oh, I thought you said that about the uv_udp_send / sendto thing. Well, if I
> want to send UDP data to a given destination and read back from it, why
> should I receive data from others?
That's always possible with UDP sockets, doesn't matter if you have
called connect() or not.
I forgot to mention that in the streams/UDP comparison: a stream is
1-to-1, UDP is not. :-)
Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 5:03 PM, Saúl Ibarra Corretgé<sag...@gmail.com> wrote:
>> Oh, I thought you said that about the uv_udp_send / sendto thing. Well, if I
>> want to send UDP data to a given destination and read back from it, why
>> should I receive data from others?
> That's always possible with UDP sockets, doesn't matter if you have
> called connect() or not.
I didn't really tried it, so I guess the man page mislead me: "If it is of type SOCK_DGRAM, this call specifies the peer with which the socket is to be associated; this address is that to which datagrams are to be sent, and the only address from which datagrams are to be received."
> I forgot to mention that in the streams/UDP comparison: a stream is
> 1-to-1, UDP is not. :-)
In my opinion this abstraction is not needed.
If the user wants an interface like this, the user can just create an
abstraction for himself. Maybe I will do something in my LibuvSharp
bindings on higher level, but I don' think that it is needed on lower
level.
What does the user do with packets which don't come from the source to
which he connected? A lot of technicalities are involved which should
be dealt with on a higher level.
On Fri, Sep 21, 2012 at 5:44 PM, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> I didn't really tried it, so I guess the man page mislead me: "If it is of
> type SOCK_DGRAM, this call specifies the peer with which the socket is to be
> associated; this address is that to which datagrams are to be sent, and the
> only address from which datagrams are to be received."
You're right, that's what the man page says and it's how it works.
Sorry, I may have been thinking of connect + multicast.
Ben Noordhuis wrote:
> On Fri, Sep 21, 2012 at 5:44 PM, Saúl Ibarra Corretgé<sag...@gmail.com> wrote:
>> I didn't really tried it, so I guess the man page mislead me: "If it is of
>> type SOCK_DGRAM, this call specifies the peer with which the socket is to be
>> associated; this address is that to which datagrams are to be sent, and the
>> only address from which datagrams are to be received."
> You're right, that's what the man page says and it's how it works.
> Sorry, I may have been thinking of connect + multicast.
On Sat, Sep 22, 2012 at 8:55 AM, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> In that case, do we want it then? :-)
Well... I'm not extremely enthusiastic but I guess that a case could
be made that it's slightly more efficient to have martian packets
dropped by the kernel.
