Re: sockets2 GenVoca layering for address

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 | 
SomeOther
> 
> Marshalling             :       NetworkByteOrder | LittleEndian | 
SomeOther
> | 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 
None however 
> 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 
decimal format. 
> I.e. "10.0.0.1" or possibly "10.0.0.1:12345". An address can not be 
created from
> a hostname or DNS name. This is because the performance 
characteristics of DNS 
> lookup are substancially slower, potentially involving a number of 
network and 
> file accesses before returning. Therefore, for converting DNS names 
to addresses
> 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 
laziness.

In other words, 

resolver r("www.boost.org");
socket_address a(r.get_primary_addr());

> Implementation
> 
> 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...

Regards,
Dave