24 Mar
2017
24 Mar
'17
7:33 p.m.
On Fri, Mar 24, 2017, at 01:37, Erik E. Fair wrote:
Andrew,
I'm a fan of Plan 9's elegance and clean design, but beware of the limitations
of the abstractions you choose. One place that files and connections don't work
cleanly is in actual datagram networking. You can do TCP easily, but UDP and especially
broadcast/multicast make a hash of the abstraction. That's how you end up with
sendto(2), sendmsg(2), recvfrom(2), recvmsg(2).
Why?
For UDP, just have the data returned from read() include the length and
source address. You could do the same for write, or require a separate
socket for each destination. You could even force-fit the read side into
the connection model; have a "listening" socket that you have to
"accept" each new source address from; but you'd still need a solution
for message lengths. I'm not familiar with the issues with
broadcast/multicast/*msg functions, but "a stream consisting of a
serialized sequence of all of whatever information would have been
supplied to/by the calls to the special function" seems like a universal
solution at the high level.