On 2008-07-21 12:54 +0000 (Mon), Aaron Denney wrote:
> On 2008-07-21, Curt Sampson <cjs at starling-software.com> wrote:
> >
> > Well, perhaps the idea there was that if you wanted to start doing this,
> > you should be using Network.Socket instead of Network, anyway.
>> Sounds reasonable to me -- my prefered solution would be to deprecate
> listenOn.... I think there is room for an easier to use interface than
> the full Network.Socket, but I don't think listenOn is it. Perhaps
> more like a parameterizable skeleton server?
Personally, I like it.
I use it myself when I just need to cons up a quick connection for
some TCP stuff that I'll replace later with a proper setup (though I
imagine I'll replace that with a library--or I'll have just memorized
the API--somwhere around my fifth networking project in Haskell).
But what I really imagined that the Network library was used for was
student projects that focused on implementing a protocol talking to or
listening on a TCP socket, where you wanted to focus on actually doing
the protocol rather than the details of binding, name lookup, and so on.
For this, it's perfect. The Network library is the equivalent of the
bits of IO that are in the Prelude (putStrLn, etc.).
> The same port will of course be connected differently on different
> machines. I think we're quibling over the meaning of namespace here,
> but e.g. port 22 is for ssh on both IPv4 and IPv6.
Indeed, but consider this: when I run netcat as "nc localhost 4321", I
won't be able to connect to the Haskell program listening on that port
on my NetBSD machine. Same goes if I use a non-v6 aware telnet with a
domain name from any other machine.
This is not a theoretical situation; I've twice in the past two weeks
had to use Network.Socket instead of Network for just this reason. And
it would have been the same on FreeBSD, from the reports I've heard.
The main thing is, there are just too many machines that don't do IPv6,
or are on networks not configured for IPv6, where perhaps the remote has
that link-local-type IPv6 address, but the connecting host doesn't.
> > I think at this point I'm preferring the simple thing: just go for
> > PortNumber Int and PortNumber6 Int data constructors, and if you want to
> > do better than that, use Network.Socket.
>> And do we also have both Service and Service6 constructors? The same
> exact issue arises.
Well, I'd always wondered what those do! :-)
Yes, I'd say the same for those.
cjs
--
Curt Sampson <cjs at starling-software.com> +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com