[boost] Re: [network] An RFC - updated

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-23 05:51:49

Don G wrote:
> 
> 
>>Under the address-centric model, the form of the
>>address determines the network to use. The library
>>is free to maintain several network objects under
>>the hood, ...
> 
> 
> There is the question of what network types does an application need.
> It is not likely they need all of them. So, the app must pre-register
> the types it wants and only those address forms will work.

I would prefer for a fixed set of networks (mainly ip/ipv6 to be 
available from start maybe lazily created on first reference). And 
registering a network creation function to the registry would let the 
registry use weak references to networks and all objects spawned from a 
network holds strong references in that way the network is destroyed 
when the last object spawned from it goes away. The network creation 
function could be passed along with an address so an address could be 
used across dll boundaries where each dll has its own registry.

> For the record, I've never needed such a map. There are so few places
> that accept or connect, and then, so few different network objects,
> that it just hasn't happened. For example:
> 
>    void tcp_tab_page::on_click_go ()
>    {
>       net::address_ptr addr = tcp_->new_address(url);
>       session_mgr->start(addr);
>    }
> 
> The method existed in a "TCP" page of a tabbed dialog, which of
> course knows that connections proceed over TCP. It created an address
> object and called into network-agnostic code to proceed.

Wouldn't you need to store the settings and then start the applications 
from the stored settings and isn't the map needed then?

>>The "self contained address as a string" model also has
>>another advantage: it allows you to take a legacy design
>>such as std::fopen and enhance it with network capability
>>in a backward-compatible way.
> 
> 
> While I still agree with the jist of your argument, I am not so sure
> everyone would appreciate their apps growing by sizeof(http_lib) +
> sizeof(ftp_lib) + sizeof(uucp_lib) + sizeof(gopher_lib) + ... to
> support this approach. :)

They could be dynamically loaded.

>>Why I prefer tcp:/host:port instead of scheme://host?
>>Let's get back to enhancing std::fopen in a backward-
>>compatible way. I'd expect fopen on
>>http://www.example.com to return the data stream
>>obtained by the corresponding GET query, for obvious
>>reasons.
> 
> 
> I'm not sure I understand the difference you are drawing between ":/"
> and "://". The way I read the URL/I syntax, many options will work.
> Here is one that would be unambiguous 
> 
>  - ipv4:tcp:http://www.boost.org
>      ipv4 denotes network choice; scheme-specifics
>      follow:
>        tcp denotes stream as opposed to datagram,
>         and again, details follow
>        http denotes how to talk say vs. HTTPS or FTP
> 
>   - ipv4:http://www.boost.org:80
>     tcp can be assumed as long as protocol doesn't
>     have udp as well (like echo or discard<g>).

I think the syntax of the address should be kept simple to use, explain 
and parse and having several ways of expressing the same thing in 
general isn't a good idea. And in that case we also would need 
canonicalization to be able to compare the addresses. Ie 
ipv4:tcp:http://www.boost.org shold be equal to 
ipv4:http://www.boost.org:80. But i guess they both could be 
canonicalized to something like tcp:/66.35.250.210:80.

>>I'm not sure. net::poll is specifically intended to
>>preserve the internal structure of your library. You
>>only need to defer dispatching the callbacks until
>>net::poll is called (unless net::async_poll is in
>>effect.)
> 
> 
> I am not sure I understand your async_poll suggestion (sorry about
> that<g>). 

As I understood it async_poll would start up a reasonable set of threads 
starting doing net::poll and dispatching events for the library in its 
own thread pool without the user having control over the pool.

 > I agree that net::poll() would fit with a common desire to
> have single threaded network programs, but might complicate things
> where the program is a GUI. Integrating with the GUI loop is a study
> in compromise (at least for Windows).

I see no reason whatso ever to have a windows gui program using the 
library to be single threaded. It would be easy enough to spawn a single 
io thread polling and handling the notifications and posting results to 
be processed by the gui. I have only gotten into trouble trying to 
integrate this kind of polling in the eventloop of a gui application and 
always moved to an simple thread model posting notifications to the gui 
thread.

> I like the idea of net::poll() for some uses, but it doesn't fit what
> I often need (GUI integration). It does fit with select/epoll
> especially on platforms where the number of objects that can go in an
> fd_set is > 64.

There still is some arbitrary limit albeit higher isn't there. The 
FD_SETSIZE can be set to a large value before including winsock (althoug 
some lsp makes presumptions about the size).

> I agree, but others don't. Some folks don't want any background
> threads; just a single thread doing one uber select/epoll call
> (again, for platforms that can handle it). The only way I can see to
> accommodate that is a different concrete network object. The ones I
> would write initially would probably not fit this desire, but again,
> the interface and behavior contract probably can.

I don't really get why that couldn't that be accomodated whitout another 
network class?

>>Passing NULL is good enough for async_read, but
>>the same can't be used with async_write to choose
>>between copy/trust-the-buffer-will-be-there semantics.

A buffer lifetime flag for the read case?

> I would be happy to entertain ideas on how to provide both kinds of
> buffer management, especially if there is a way to eliminate as much
> cost as possible (in terms of "if checks" and code linkage) when
> automatic is never used.

I really don't see how some if checks and linking against 
std::vector<char> could bear any costs in terms of performance of a 
network library.

/Michel