From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-02-26 13:09:11
> socket address Feature Model
> address : address [ Representation ,
> Marshalling ,
> TransmissionType ,
> Location ]
> Representation : sockaddr_in | sockaddr_in6 |
> Marshalling : NetworkByteOrder | LittleEndian |
> | None
> TransmissionType : Unicast | Broadcast | Multicast
> Location : Local | Remote
> In practice, Representation would be a Protocol Traits class.
> Marshalling is, in every case I am aware of, NetworkByteOrder or
> the possible variation point allows for the future ( as the C
socket API does as
> well ).
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...
> This class can only be constructed with strings in the dotted
> I.e. "10.0.0.1" or possibly "10.0.0.1:12345". An address can not be
> a hostname or DNS name. This is because the performance
characteristics of DNS
> lookup are substancially slower, potentially involving a number of
> file accesses before returning. Therefore, for converting DNS names
> and services to ports see resolver.
This seems fine, as long as your resolver design allows for a succint
syntax with the socket address class so that users aren't motivated
to avoid deailing with hostnames -and- dotted decimal names out of
In other words,
> To avoid having platform headers in the boost networking headers, I
have created, for instance csocket.h as my implementation of socket.h
and am in the process of doing this for cinet.h and all the other
platform headers specifically used for sockets.
Could you be a bit more specific about what is inside these headers?
I ran up against this requirement during my own attempt at a socket
library, and I'm interested in the different techniques used here.
I wound up dynamically allocating my sockaddr_in's from a .cpp file
of a protcol_traits class, which seemed klunky to me...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk