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
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
>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,
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.
>> To avoid having platform headers in the boost networking headers, I
>>have created, for instance csocket.h as my implementation of
>>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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk