Boost logo

Boost :

From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-02-27 09:42:27


      
> >Are you talking about marshalling of the individual members of the
> >underlying socket address representation, or all marshalling of
data
> >that will eventually take place on a connection to this network
> >address? If you're just talking about the representation of the
> >address, I would say that this is a degree of freedom that is not
> >needed for real world sockets stuff...
>
> I'm refering to marshalling network & transport address ( port ). I
> would say that this degree of freedom is necessary because it is
> possible to build an address with either premarshalled data or
> unmarshalled data.

Fair enough, and once I thought about it, this is almost always known
as compile time. Might complicate things like assignment operators
or comparisons, but this is worth it to eliminate the common error of
missing htons() on a port...

      
> I have only roughly modeled the resolver, so far but yes, I would
expect it to
> be at least that simple. I would probably prefer a free function
that allowed
> getting the primary directly, such as:
>
> address Server_Address ( primary_address ( "www.boost.org" );
>
> maybe at layered on top of this there could be a resolvable_address.

Looks reasonable... Most people don't need to dig down to alternate
addresses that the resolver returns, but some people will, and the
free function keeps it simple for most people...

As for the csocket.h, cinet.h, etc., you'll need one of these for
each platform flavor, especially for the older IPv4 stuff.... To
pick a specific example, some versions of BSD have an 8 bit length
member in the sockaddr_in structure and an 8 bit address_family
member, while Winsock and other Unices have a 16 bit address_family
and no length member.

I think you *can* reasonably "size" your structures in a common
header based on public specifications/standards, but there is no
getting around the fact that any platform independent library will
need platform specific structure handling code for variations like
the one above.

Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk