Hi Caleb,
Hm, hadn't thought of non-IP. What protocols out there which support a port/channel concept use a larger port range than TCP/IP? Just curious.
When I was writing the HTTP/reflection system, we (at my work) noodled around with a Mac-like 4CHARS concept (L'HTTP' or L'PTTH' for the little-endians<G>) for ports.
* timeout constructors are inconsistent. One takes
What about Bob Bell's suggestion of using double? Would there be concerns about the overhead in all of the double -> integer conversions necessary to interface with the various OS-level APIs? Having constructors from a few possible argument types (e.g. double, int seconds + int <subseconds type TBD>) seems to make sense.
I like the multiple ctors approach. Is this roughly what you have in mind? timeout (uint_t seconds, uint_t micros); timeout (uint64_t microsecs); timeout (double seconds);
As far as the appropriate subseconds type goes, we should probably pick the highest-possible resolution that makes sense, which I'd contend is probably microseconds. Some operating systems may be able to slice time (and signal events) at resolutions below milliseconds, but I doubt any can go deeper than microseconds.
I agree. I can't imagine ever specifying any timeout < 1us. :)
I think I see your point here, but I'm not 100% convinced that this is the right place to put url. It seems to me that the concept of URL belongs at a higher level, since the only portion you can use at the network level is a hostname and port. It might be expedient for a high-level HTTP library to be able to pass URLs all the way down to the network level, but it would be nearly as easy for that library to make use of its own URL object which had methods for extracting the "address_specifier" information.
I guess that I felt the world only needed one way to describe an address in textual form. Different consumers want different pieces, but they can all "just get along"; the URL is plenty accommodating.<g> Also, there is a "hidden" aspect to this. For example, "http://www.boost.org" is as valid to new_address as "www.boost.org:80". The "http" scheme provides indirection back to the port mapping table and, therefore, configuration by the app. Now, "http" might not be the best example, but I've used this technique for homegrown protocols. This allowed me to have an indirection between config file URL values and actual port number.
Does anyone else have an opinion on this?
Anyone? :)
I'd contend that in general, an operating system supplied multiplexing facility will scale better than one that uses a thread to handle each connection.
Absolutely. The code I have in mind uses a thread pool and connections are managed by as few a number of threads as necessary.
OK, having read a number of your posts on this subject, I think I am starting to understand your position w/r/t event dispatch. Correct me if I'm wrong, but your contention is that these mechanisms are best left hidden from the user, and the interface should expose only synchronous operations or async/non-blocking operations with some sort of callback mechanism. How those are implemented is not exposed.
Exactly - at least within the limits of the English language vs. C++<g>.
This is a bit of a paradigm shift for someone (e.g. me) who is comfortable with select and fd_sets, etc, and even some of the higher level abstractions like ACE_Reactor. But I can see the value in this hiding approach and might warm to it if the implementation is easy to use and performs well.
I can say that I have found it very easy to use. :) Performance is always a matter of what measure one wants to use (or rather, what test case). I have stressed it well beyond the needs of my own applications (see previous posts), and found that it performed acceptably. I would like to see how well it performs for other folks. If performance issues turn up, I am confident that a great deal of optimization can be applied with little or no impact on the interfaces (the benefit of encapsulation, right? ;).
The threads in this pool are only doing I/O multiplexing, so I'm not sure I understand your concern.
The point was several paragraphs of navel-gazing about how the underlying multiplexing implementation might work. Clearly you understand the mechanisms involved, so my dialectic was wasted :)
Anyway, yours is a new approach to me, but I think I can see its value and would be interested in trying it out.
I am proceeding along fleshing out the boost-ified interfaces, but the sandbox is not so friendly a place to post constantly changing files. Is there an FTP-like repository or public CVS/whatever? Perhaps I need to create a folder in the sandbox, so I could delete obsolete files. I'm not sure the best answer here... Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/