From mboxrd@z Thu Jan 1 00:00:00 1970 From: random832@fastmail.com (Random832) Date: Fri, 24 Mar 2017 09:33:02 -0400 Subject: [TUHS] Were all of you.. Hippies? In-Reply-To: <2595.1490333837@cesium.clock.org> References: <2595.1490333837@cesium.clock.org> Message-ID: <1490362382.1722733.922188992.774B4678@webmail.messagingengine.com> 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.