[boost] Re: [network] An RFC posted to the sandbox

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-14 21:48:58

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/