Proposal: ByteString based datagram communication (Ticket #1238 )

[Robert Marlow]

I think this is a bit of a sidetrack from the goal of this patch but I
agree; It would definitely be nice to be able to easily extend the API
in such a manner.

My goal in this particular patch was to give a set of (primarily UDP)
datagram functions with an interface analogous to what existed for the
stream (TCP) functions. TCP and UDP are currently the primary network
technologies used today. Though DCCP (and ICMP) would be nice too.

My knee-jerk opinion is that the current use of HostName and PortID
already assume IPv4 protocols such as TCP and UDP more than they could.
Unix socket functions for example make no use of the HostName argument
at all and the UnixSocket constructor just doesn't sound like it fits
the name of the type "PortID" to me. Consequently, I think making the
Network module more flexible for extension would involve getting rid of
the current addressing scheme and implementing some new Address type
which includes not just the address, but the protocol used. So something
like

data Address = TCP HostName PortNumber
             | UDP HostName PortNumber
             | DCCP HostName PortNumber
             | UnixSocket FilePath
-- Maybe also inet6:
             | TCP6 HostName6 PortNumber
             | UDP6 HostName6 PortNumber

and so forth. Of course this is beyond the scope of this patch.


On Thu, 2007-04-05 at 02:32 -0700, John Meacham wrote:
> you might want to consider any API consequences of supporting DCCP
> 
> http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol
> 
> I am not saying full DCCP support is needed off the bat, but it would be
> nice if at some point in the future the API could be extended gracefully
> to support it as well as UDP as far as unreliable datagram style
> communication goes.
> 
>         John

-- 
Robert Marlow
MITS Co-operative Limited
http://www.mits.coop/