Hi Chris, --- Chris Cleeland <cleeland@ociweb.com> wrote: <snip>
(a) buffers: from a certain perspective, this sounds nice, but it seems that there are already so many abstractions over a (void* + length)
There are? :)
--do we REALLY need another? Could this be simplified to something like std::pair<void*, std::size_t> ?
Conceptually, mutable_buffer does behave like std::pair<void*,size_t>, and const_buffer is like std::pair<const void*,size_t>. However, unlike just using std::pair, the buffer classes also: - Make type-safety violations explicit (although not impossible) by requiring you to use buffer_cast. - Provide some protection against buffer overruns by only allowing smaller buffers to be created from larger ones.
I don't see how one can get hold of the raw socket descriptor to twiddle options that the library hasn't abstracted.
Two methods: - Use the impl() member function to get access to the underlying platform-specific implementation. E.g.: ::setsockopt(sock.impl(), ...); - Implement the Socket_Option concept for the option. <snip>
I also know that after 15+ years of network programming, KNOWING the details all the way down to the wire is important for how one writes code.
If an application requires that level of control, then asio is probably not the appropriate tool.
Purists may say that one should never make such assumptions, but the reality is that when your "wire" is gigabit ethernet you get to write code with a certain set of assumption that is completely different from assumptions in place when the "wire" are high-bandwidth/high-latency satellites in geosynch orbit.
I'm genuinely curious to know what assumptions are different between those two specific scenarios, with respect to demultiplexing. <snip>
Is hostname resolution really so much of an overhead that we need asynch hostname resolution? If the feature were basically "free", I would say okay, but the fact that it requires firing up an extra thread behind the scenes (another one of my pet peeves) makes it seem like a wholly unnecessary feature.
The issue here is that hostname resolution is a potentially lengthy operation. If resolution is only performed at program startup, then that might be ok. However, if a server needs to resolve hostnames on a regular basis, you would not want to block the flow of control and delay other clients. If the synchronous operations were all that was on offer, the only course open to the application developer would be to use threads. The asio philosophy is to offer application developers support for concurrency without the need to use threads directly. As a bonus, some platforms do provide asynchronous host resolution APIs, and I hope to support these over time. This would be transparent to users of the asynchronous host resolution.
Besides the fact that this style is "wierd" to me (that's a personal thing), this implementation choice forces users' hands down the line. First, it forces all the code in the "library" to be replicated in every executable. This is not efficient and increases footprint.
It is on my to-do list to add support for a library implementation. However the goal of this is to prevent system headers from polluting the application's namespace. Since most of the library is template-based, I don't expect it to make much difference to the footprint (although you never know).
4. How would I implement a timed write with the current async API? By "timed write", I mean that I want to write some hunk of data, but I need to know if the write hasn't completed within a certain window of time. This is a common need in performance-sensitive systems, and writing it synchronously can be done, but how do I write it asynch?
The timing bit is easy: just set the expiry on a deadline_timer and perform an asynchronous wait. However the real question is what to do once the timer fires :) Can you describe the wider use case in more detail? In particular, what you intend to do with the socket if the "timed write" times out. At the moment the way to cancel operations in asio is to close the socket. All pending asynchronous operations complete with the operation_aborted error.
5. TSS and threads Shouldn't these rely on boost.thread? I'm especially thinking of TSS in this case, bceause in ACE/TAO we've found that TSS is, at the very least, inconsistent across platforms. See changelog entry in ACE_wrappers/Changelogs/ChangeLog-05a for one of t he more aggregious examples.
Wed Feb 16 16:18:45 2005 Dale Wilson <wilson_d@ociweb.com>
Unlike both Boost.Thread's and ACE's TSS implementation, the TSS wrapper in asio provides absolutely no ownership or cleanup semantics, thus avoiding painful issues like the ones mentioned in that ChangeLog entry. It's used only to store a pointer to a variable on the stack. Cheers, Chris