Boost logo

Boost :

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 18:05:39

Peter Dimov wrote:
> 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, ...

I also prefer the address centric approach since it feels more natural.

Also I wonder what would be the hooks to register new network
implementations and provide the notification mechanisms for those.

> 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
> to return the data stream obtained by the
> corresponding GET query, for obvious reasons.

This is a good example on a very specific connector that posts a GET
operation to initialize the stream for the handler in this case to treat
an url as a file.

>> All of these are forcing TCP/IP (IPv4 even<g>) concepts to the user.
>> The central idea of the abstraction I proposed is that "datagram" and
>> "stream" are the behavior-bundles to which one should write
>> protocols, not TCP/UDP or sockets. The notion of loopback and
>> broadcast can carry over from one network type to another, but these
>> textual forms do not.
> Yes; another manifestation of the network issue. I agree that in a
> network-centric design your approach is preferable. In an
> address-centric design, the TCP/IP4 broadcast address is not portable
> between networks.

Is it a problem that the special or specific adresses is represented by
different textual representations for different networks? I guess a
textual representation could be devised that makes these look the same
with some psuedo notation. Like broadcast tcp:/[broadcast]:1234,
tcp6:/[broadcast]:1234, local tcp:/[local]:1234, tcp6:/[local]:1234, any
tcp:/[any]:1234, tcp6:/[any]:1234 this would i guess alleviate some of
the eventual problems.


Boost list run by bdawes at, gregod at, cpdaniel at, john at