Re: [Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
On 2009 Feb 27, at 4:25, Colin Paul Adams wrote: Anyway, the POSIX spec indicates the EOF condition as return -1 with errno == ECONNRESET; this should not be taken as anything but the limited expressiveness of a C-based API. We should map this return to Nothing. Johan I'm not sure I agree. I think using exceptions in this case is fine as Johan loosing the connection is indeed an exceptional condition and the best Johan thing a program can do in this case is probably to abort processing of Johan the disconnected client. I guess this depends upon how exceptional you want an exception to be. To my mind, a lost connection is a fairly normal condition (FAR to normal for my teleworking situation :-( ). That is, I would expect the exception to occur rather than not, during one run of a program. On that basis, I would suggest Nothing is better than an exception. Actually, thinking about this, ECONNRESET can be a normal end-of- connection for TCP, but for UDP should never happen (on recv(); on send() it is surely an exception). But at the same time, if you're using recv() with TCP you are probably not working with a higher level protocol that simply shuts down the connection when it's done: it's more of a stream-oriented behavior, and the stream-oriented read() handles it as such. That said I have heard of cases where recv() is used for stream protocols for efficiency reasons. I don't know if the efficiency argument relates to anything newer than a PDP11 or VAX 750, though -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
On Fri, Feb 27, 2009 at 12:07 AM, Achim Schneider bars...@web.de wrote: Bryan O'Sullivan b...@serpentine.com wrote: There's another problem with the network APIs: they mirror the BSD socket API too faithfully, and provide insufficient type safety. You can try to send on an unconnected socket, and to bind a socket that's already connected, both of which should be statically forbidden. The APIs for datagram-oriented networking ought to be distinct from the stream-oriented variety, I think, even if the underlying C-level calls end up being substantially the same. Iteratees to the rescue? Ideally, we'd have a composable IO system that's uniform across different types of IO. I would very much like that. However, even after thinking about the problem for several problems I don't know of a generic definition that feels right. Hopefully someone smarter will come up with one. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
2009/2/27 Brandon S. Allbery KF8NH allb...@ece.cmu.edu: On 2009 Feb 26, at 23:41, Achim Schneider wrote: Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 26, at 16:45, Johan Tibell wrote: Anyway, the reason recv doesn't return 0 is that if you have a datagram socket, a zero-length recv is valid and doesn't mean EOF. My man page says a retval of 0 means that the peer has performed an orderly shutdown, which, in the UDP case, means that it has send a complete datagram... no mention of EOF. A true EOF in the sense of no more data will be received would mean unbinding the socket. Right. Just have to realize that a zero-length datagram packet is possible and even meaningful, so 0 isn't available as an EOF flag. If this is the case then the Network.Socket module is broken when used for UDP as it throw an exception on receiving a valid message. Anyway, the POSIX spec indicates the EOF condition as return -1 with errno == ECONNRESET; this should not be taken as anything but the limited expressiveness of a C-based API. We should map this return to Nothing. I'm not sure I agree. I think using exceptions in this case is fine as loosing the connection is indeed an exceptional condition and the best thing a program can do in this case is probably to abort processing of the disconnected client. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
Anyway, the POSIX spec indicates the EOF condition as return -1 with errno == ECONNRESET; this should not be taken as anything but the limited expressiveness of a C-based API. We should map this return to Nothing. Johan I'm not sure I agree. I think using exceptions in this case is fine as Johan loosing the connection is indeed an exceptional condition and the best Johan thing a program can do in this case is probably to abort processing of Johan the disconnected client. I guess this depends upon how exceptional you want an exception to be. To my mind, a lost connection is a fairly normal condition (FAR to normal for my teleworking situation :-( ). That is, I would expect the exception to occur rather than not, during one run of a program. On that basis, I would suggest Nothing is better than an exception. But I guess it depends upon the program. For long running servers, my expectation above is surely true. But other servers might not share the same expectation. Perhaps it should be configurable? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
Johan Tibell johan.tib...@gmail.com wrote: I'm also interested in understanding the reasons behind the design of the `recv` function in the network library. POSIX semantics. And, frankly, I'm opposed to messing with them: If you want to have different behaviour, please do a (different|wrapper) library. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
Achim Schneider bars...@web.de wrote: Johan Tibell johan.tib...@gmail.com wrote: I'm also interested in understanding the reasons behind the design of the `recv` function in the network library. POSIX semantics. And, frankly, I'm opposed to messing with them: If you want to have different behaviour, please do a (different|wrapper) library. Ouch. I revoke. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
Bryan O'Sullivan b...@serpentine.com wrote: There's another problem with the network APIs: they mirror the BSD socket API too faithfully, and provide insufficient type safety. You can try to send on an unconnected socket, and to bind a socket that's already connected, both of which should be statically forbidden. The APIs for datagram-oriented networking ought to be distinct from the stream-oriented variety, I think, even if the underlying C-level calls end up being substantially the same. Iteratees to the rescue? Ideally, we'd have a composable IO system that's uniform across different types of IO. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 26, at 16:45, Johan Tibell wrote: definition of `recv` would look like. My current thinking is that it would mimic what C/Python/Java does and return a zero length ByteString when EOF is reached. Ew. Isn't this what Maybe is for? Anyway, the reason recv doesn't return 0 is that if you have a datagram socket, a zero-length recv is valid and doesn't mean EOF. My man page says a retval of 0 means that the peer has performed an orderly shutdown, which, in the UDP case, means that it has send a complete datagram... no mention of EOF. A true EOF in the sense of no more data will be received would mean unbinding the socket. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coming up with a better API for Network.Socket.recv
On 2009 Feb 26, at 23:41, Achim Schneider wrote: Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 26, at 16:45, Johan Tibell wrote: definition of `recv` would look like. My current thinking is that it would mimic what C/Python/Java does and return a zero length ByteString when EOF is reached. Ew. Isn't this what Maybe is for? Anyway, the reason recv doesn't return 0 is that if you have a datagram socket, a zero-length recv is valid and doesn't mean EOF. My man page says a retval of 0 means that the peer has performed an orderly shutdown, which, in the UDP case, means that it has send a complete datagram... no mention of EOF. A true EOF in the sense of no more data will be received would mean unbinding the socket. Right. Just have to realize that a zero-length datagram packet is possible and even meaningful, so 0 isn't available as an EOF flag. Anyway, the POSIX spec indicates the EOF condition as return -1 with errno == ECONNRESET; this should not be taken as anything but the limited expressiveness of a C-based API. We should map this return to Nothing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
