asio review: are we still on topic?
Guys, This general discussion about which approach to networking is superior is very interesting (and useful for me personally), but I think we moved off topic. I think Chris (the author of asio) agreed that both approaches are valid, and claimed he gives both of them appropriate attention. So now, since I pointed to what I believe is a problem with the synchronous interface in asio (socket dependency upon the demuxer), doesn't the critique of synchronous approach sounds a little bit like: "It is inferior anyway, so it's a goot thing that it's not clean" ? Because nobody yet tried to convince me that socket dependency upon demuxer (even if for synchronous IO only) is a good thing. Regards, Arkadiy
Arkadiy Vertleyb wrote:
Guys,
This general discussion about which approach to networking is superior is very interesting (and useful for me personally), but I think we moved off topic.
I think Chris (the author of asio) agreed that both approaches are valid, and claimed he gives both of them appropriate attention.
So now, since I pointed to what I believe is a problem with the synchronous interface in asio (socket dependency upon the demuxer), doesn't the critique of synchronous approach sounds a little bit like:
"It is inferior anyway, so it's a goot thing that it's not clean" ?
Because nobody yet tried to convince me that socket dependency upon demuxer (even if for synchronous IO only) is a good thing.
Heh, I actually agree with you that it seems a bit ugly/strange. I wouldn't be using the synchronous part anyway, so I don't really care all that much, though. :) -- Bardur Arantsson <bardurREMOVE@THISimada.sdu.dk> <bardurREMOVE@THISscientician.net> - It's just like the story of the grasshopper and the octopus. All year long, the grasshopper kept burying acorns for the winter, while the octopus mooched off his girlfriend and watched TV. But then the winter came, and the grasshopper died, and the octopus ate all his acorns. And also he got a racecar. Is any of this getting through to you? Fry, 'Futurama'
So now, since I pointed to what I believe is a problem with the synchronous interface in asio (socket dependency upon the demuxer) ...
Exactly - in my own (soon upcoming, hopefully) Asio review I mention that I see the Asio demuxer as a general asynch I/O demuxer (which is also what I understand Chris intends). E.g. the demuxer could be used for file I/O, and in that case there should be interfaces (eventually) to use Boost.Filesystem with the demuxer. Of course the (current) synchronous Filesystem interfaces will not go away. The same could be said for many other (currently synchronous only) libraries. I don't think Sockets should be an exception - i.e. Sockets can only be used with a demuxer, but Filesystem can be used without. We can argue about the most efficient and scalable way to design high-performance network applications, but there will always be use cases for small, simple, synchronous socket libraries. As long as there is well-documented and easy paths to the higher-performance asynchronous interfaces, I see real advantages to layering it this way. This takes nothing away from the high quality of Asio, and I would even be happy with taking Asio as is, with a future path towards the simpler synchronous socket operations. Cliff
Hi Cliff, --- Cliff Green <cliffg@codewrangler.net> wrote:
Exactly - in my own (soon upcoming, hopefully) Asio review I mention that I see the Asio demuxer as a general asynch I/O demuxer (which is also what I understand Chris intends). E.g. the demuxer could be used for file I/O, and in that case there should be interfaces (eventually) to use Boost.Filesystem with the demuxer. Of course the (current) synchronous Filesystem interfaces will not go away. The same could be said for many other (currently synchronous only) libraries. I don't think Sockets should be an exception - i.e. Sockets can only be used with a demuxer, but Filesystem can be used without.
We can argue about the most efficient and scalable way to design high-performance network applications, but there will always be use cases for small, simple, synchronous socket libraries. As long as there is well-documented and easy paths to the higher-performance asynchronous interfaces, I see real advantages to layering it this way.
Since you mention files, it's worth remembering that the synchronous abstraction for files in the standard library is iostreams. I think it is reasonable to include a socket iostream class that is layered on top of asio and hides all of the asynchronous stuff away, simply because iostreams are a part of the standard library that most people are already familiar and comfortable with. I now intend to add one (i.e. turn the current iostreams example into part of the library), although I'm not yet quite sure what the programming interface should be (and whether it would require another review?). However, we must be careful here. Sockets are not files. With files you can get away with synchronous operations in all sorts of places because they are usually fast. For example, you can perform file I/O in a user interface thread and the user is unlikely to be aware of any delay. Socket operations, on the other hand, can involve delays many orders of magnitude larger. Networks introduce latency. Socket read operations can continue indefinitely with no data arriving on the socket. These issues are inherent in network programming. No synchronous interface can hide them away. In all but the simplest applications, it is a matter of when, not if, they will need to be addressed. As I have mentioned elsewhere, I believe that it is when programmers reach this point that exposure only to synchronous interfaces, and no awareness of asynchronous, can limit their consideration of appropriate designs. Therefore I also believe it will be counterproductive to offer a lower-level synchronous-only API, a "false economy" if you like. Asynchronous I/O is not only applicable for high performance and scalability. The big advantage for applications of any size is that it offers concurrency without threading. In my experience, multithreading is more error prone than asynchronous I/O. So to reiterate, I think the appropriate way to provide a synchronous sockets API is an iostreams-based interface, and as suggested I intend to include one in asio. When developers start to find the iostreams interface too limiting, I feel that is when they are probably ready to be introduced to asynchronous I/O. Cheers, Chris
On Thu, 15 Dec 2005 15:29:05 -0500, Arkadiy Vertleyb wrote
Guys,
This general discussion about which approach to networking is superior is very interesting (and useful for me personally), but I think we moved off topic.
I agree, I think this discussion has moved off-topic and would like to see us refocus on the library under review. I agree with Arkadiy that we do need to determine if the synchronous interfaces can be improved or if we are happy with them as-is. I think Chris has provided some rationale, but I hope the pros and cons will be discussed futher... Jeff
participants (5)
-
Arkadiy Vertleyb -
Bardur Arantsson -
Christopher Kohlhoff -
Cliff Green -
Jeff Garland