code review 134150043: net: Enable use of WriteTo with datagram sockets withou...

net: Enable use of WriteTo with datagram sockets without connect.

I ran into this while trying to make a program that would send debug info to a unixgram socket without there neccesarily being something listening there at any given time.

Could probably do with a better description here...

[albert.strasheim, 2014-08-30 05:04:47]

Hello bradfitz@golang.org, dvyukov@google.com (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[albert.strasheim, 2014-08-30 05:08:52]

Hello bradfitz@golang.org, dvyukov@google.com, mikioh.mikioh@gmail.com (cc:
golang-codereviews@googlegroups.com),

Please take another look.

[mikio, 2014-08-30 05:48:32]

i'm now trying to land cl  85630044 in go1.4, so can you please explain what
happens to the matrix? also don't we need to able to make unnamed datagram-based
Conn and/or PacketConn using Dial and ListenPacket? i personally don't want to
see any unnecessary inconsistency btw ListenPacket and Listen{UDP,Unix}, Dial
and Dial{UDP,Unix}.

// TODO(mikio): This is a part of test case reafactoring work, but
// still incomplete.
//
// Connected-mode:
//                      inet4/inet6             unix
//                      stream  dgram   seqpkt  stream  dgram   seqpkt
// -------------------------------------------------------------------
// Write                ok      ok      n/a     ok      ok      ok
// WriteTo              --      --      n/a     --      --      --
// WriteToProto         --      --      n/a     --      --      --
// WriteMsgProto(*)     n/a     --      n/a     ok      --      ok
// io.ReaderFrom        ok      --      n/a     ok      --      --
//
// Unconnected-mode:
//                      ient4/inet6             unix
//                      stream  dgram   seqpkt  stream  dgram   seqpkt
// -------------------------------------------------------------------
// Write                --      --      --      --      --      --
// WriteTo              --      ok      --      --      ok      --
// WriteToProto         --      ok      --      --      ok      --
// WriteMsgProto(*)     --      ok      --      --      ok      --
// io.ReaderFrom        --      --      --      --      --      --
//
// *) Windows port doesn't implement it yet

[mikio, 2014-08-30 06:08:32]

plus... once we have an unnamed datagram-based Conn, we also want to
have a feature something like multiple/rotary Dial calls w/ unnamed
datagram-based Conn (yup, it's pretty common for writing small
initiators). do you have a sketch for this API?

[albert.strasheim, 2014-08-30 14:51:03]

On 2014/08/30 06:08:32, mikio wrote:
> plus... once we have an unnamed datagram-based Conn, we also want to
> have a feature something like multiple/rotary Dial calls w/ unnamed
> datagram-based Conn (yup, it's pretty common for writing small
> initiators). do you have a sketch for this API?

Don't quite understand what you mean here. Could you explain more or show some
code for this idea?

Cheers

[albert.strasheim, 2014-08-30 15:00:16]

Hello

On 2014/08/30 05:48:32, mikio wrote:
> i'm now trying to land cl  85630044 in go1.4, so can you please explain what
> happens to the matrix? also don't we need to able to make unnamed
datagram-based
> Conn and/or PacketConn using Dial and ListenPacket? i personally don't want to
> see any unnecessary inconsistency btw ListenPacket and Listen{UDP,Unix}, Dial
> and Dial{UDP,Unix}.

I think I agree with the general idea of keeping things consistent.

One consideration is maybe that if someone is calling Dial(net, nil), they might
have a bug, but if they call DialUnix("unixgram", nil, nil) they've probably
know what they're doing.

Maybe we shouldn't try to be clever. Dial("unixgram|udp", nil).Write() will fail
with ENOTCONN on the first Write anyway.

> // TODO(mikio): This is a part of test case reafactoring work, but
> // still incomplete.
> // Connected-mode:
> //                      inet4/inet6             unix
> //                      stream  dgram   seqpkt  stream  dgram   seqpkt
> // -------------------------------------------------------------------
> // Write                ok      ok      n/a     ok      ok      ok
> // WriteTo              --      --      n/a     --      --      --
> // WriteToProto         --      --      n/a     --      --      --
> // WriteMsgProto(*)     n/a     --      n/a     ok      --      ok
> // io.ReaderFrom        ok      --      n/a     ok      --      --
> //
> // Unconnected-mode:
> //                      ient4/inet6             unix
> //                      stream  dgram   seqpkt  stream  dgram   seqpkt
> // -------------------------------------------------------------------
> // Write                --      --      --      --      --      --
> // WriteTo              --      ok      --      --      ok      --
> // WriteToProto         --      ok      --      --      ok      --
> // WriteMsgProto(*)     --      ok      --      --      ok      --
> // io.ReaderFrom        --      --      --      --      --      --
> //
> // *) Windows port doesn't implement it yet

Do you mean that these are tests that exist today?

In matrix terms, I think we were missing the unconnected mode/WriteTo tests for
unix dgram and inet[46] dgram, so these don't work right.

Regards

Albert

[mikio, 2014-08-31 03:12:59]

On Sat, Aug 30, 2014 at 11:51 PM,  <fullung@gmail.com> wrote:

> Don't quite understand what you mean here. Could you explain more or
> show some code for this idea?

e.g.,
struct sockaddr dsts[N]
s = socket(..., SOCK_DGRAM, ...) // unnamed datagram socket
for i = 0; i < N; i++ {
    connect(dsts[i], ....);
    write(s, ....);
}

[mikio, 2014-08-31 04:21:56]

hi,

generally i like your proposal; to add supporting unnamed
datagram-based Conn and PacketConn support. i think it'd be useful to
make stuff that needs to be re-plumbed dynamically without worrying
about namespace conflict, limitation and restriction.

On Sun, Aug 31, 2014 at 12:00 AM,  <fullung@gmail.com> wrote:

> I think I agree with the general idea of keeping things consistent.

at the same time i'd also take care of this stuff because the net
package API is broad and layering down across over platforms and
protocols.

> One consideration is maybe that if someone is calling Dial(net, nil),
> they might have a bug, but if they call DialUnix("unixgram", nil, nil)
> they've probably know what they're doing.
>
> Maybe we shouldn't try to be clever. Dial("unixgram|udp", nil).Write()
> will fail with ENOTCONN on the first Write anyway.

can we discuss your proposal at golang-dev before digging up the
implementation detail? (though, i'm not sure wether all
unix/unixgram/unixpacket protocols work as we expect). looks like i'm
still not clear on your motivation and use cases.

--
> Do you mean that these are tests that exist today?

no, under the review. see https://codereview.appspot.com/85630044/

> In matrix terms, I think we were missing the unconnected mode/WriteTo
> tests for unix dgram and inet[46] dgram, so these don't work right.

named or unnamed, connected or unconnected, connection-oriented or
connectionless, byte stream io support or datagram/segment io support.
what leaky abstractions!

[albert.strasheim, 2014-09-01 17:20:43]

Hello

On Sat, Aug 30, 2014 at 8:12 PM, Mikio Hara <mikioh.mikioh@gmail.com> wrote:
> On Sat, Aug 30, 2014 at 11:51 PM,  <fullung@gmail.com> wrote:
>> Don't quite understand what you mean here. Could you explain more or
>> show some code for this idea?
> e.g.,
> struct sockaddr dsts[N]
> s = socket(..., SOCK_DGRAM, ...) // unnamed datagram socket
> for i = 0; i < N; i++ {
>     connect(dsts[i], ....);
>     write(s, ....);
> }

I guess it depends on whether you care about whether the remote end is
listening or not.

In my case, I want to send even if something isn't listening on the
other side, so WriteTo suffices, with one adress or a slice of them.

This allows services to start and restart in any order, and allows the
sending application to set up its socket once and not worry about
dealing with ECONNREFUSED if the remote end isn't there.

Regards

Albert

[gobot, 2014-12-19 05:12:40]

R=close

To the author of this CL:

The Go project has moved to Gerrit Code Review.

If this CL should be continued, please see the latest version of
https://golang.org/doc/contribute.html for instructions on
how to set up Git and the Go project's Gerrit codereview plugin,
and then create a new change with your current code.

If there has been discussion on this CL, please give a link to it
(golang.org/cl/134150043 is best) in the description in your
new CL.

Thanks very much.