Re: [boost] Re: sockets2 GenVoca layering for address

From: Iain.Hanson_at_[hidden]
Date: 2002-02-27 09:02:21

Author:  dmoore (dmoore_at_[hidden]) at unix,mime
Date:    26/02/02 18:09

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

I can't remember how OSI handles transport selectors ( I need to look 
it up ) but it may also be required to support more esoteric 
protocols. The C sockets libtrary handles this variation point by 
making the user call inet_addr & inet_ntoa or the newer inet_pton & 
inet_ntoa instead of the stack handling this for you.
     

     
>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());

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

Give me a couple of days and I'll post them to the files section. 
They will be incomplete, as I grow them as I need things. I've based 
them on information from POSIX XNS issue 5.2 draft 2.0, IANA 
published information and IETF RFC's and some constant values I 
obtained from the FreeBSD implementation.

Csocket.h ( note the .h and not .hpp ) contains the constants for 
address family and protocol family and the function declarations for 
accept () connect() etc.
     
>I wound up dynamically allocating my sockaddr_in's from a .cpp file 
>of a protcol_traits class, which seemed klunky to me...

Not a desirable thing for a level 1 sockets library. Dynamic memory 
allocation at this level should be a user choice, not imposed by the 
library.
     
     
     /ikh

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.