Re: [boost] Re: sockets Interface for address class

From: Iain.Hanson_at_[hidden]
Date: 2002-02-28 08:22:59

Author:  davlet.panech (davlet_panech_at_[hidden]) at unix,mime
Date:    27/02/02 20:23

     
>I have a few suggestions:
>- You missed the const modifiers in a few places

Thanks. I've fixed that and will post it to the files in socket2/address.html
which also has the GenVoca grammer in it. Whilst reviewing the interface for 
const correctness I realised that port_type should be passed be reference and 
not by value as OSI has arbitary size transport selectors and there is no 
guarantee that other protocols in the future will stick to a selector compatible
with built in types.

>- I think operations involving strings should use std::string, not 
>char arrays (except perhaps the non-explicit constructor, so that 
>implicit conversions from string literals are possible)

There is no need for an address class to store the string it is 
constructed with as this would greatly increase its size. It just 
marshalls the string into an address_representation. Conversation 
back to human readable form is typically for logging and therefore 
the cost of converting from representation to presentation form is 
negligable in comparrison to the run time overhead of I/O so its  
not worth storing the string.

- I think it would make sense to provide conversion to an unspecified 
"native" type (such as sockaddr)

Why? As I said in my previous posting, I can't see any good reason for 
doing this. And I have no desire to encourage mixed mode programming 
which would be very type unsafe. I don't see the point in a user building 
a safe C++ address class to use with C socket api.

- We also need a few special pre-deined IP addresses (like loopback).

These would go in a protocol traits class. For IPv4 the default is 127.0.0.1 but
in fact any 127 /8 is a legal loopback address. For IPv6 it is just a single 
value of 0:1

[ snip ]
     
     
>I also considered using a separate IP address class (I was thinking 
>about supporting "raw" IP sockets), which would incorporate the name 
>resolution services; in this case all `IP address' parameters in the 
>above class would be of type `ip_address' instead of `std::string'. 

see below.
     
>Actually, I think the representation of addresses is the least of 
>our problems when designing a socket library. The way I see it, we 
>should concentrate on things like protocol, blocking policies, and 
>the actual socket abstractions first, since it is not obvious how to 
>design these things. How do we implement non-blocking operations? 
>Asynchronous events (like disconnect indications)? What about error 
>handling?

It is the 1st abstraction we need when building a socket library and 
much of the core of the library is dependant on it. Hopefully, from 
little acorns, a great oak tree will grow ;-). 
     
>Also from your explanations I take it that your socket library is 
>modelled after BSD sockets. I think it would be reasonable to at 
>least try designing a system that be implemented without BSD 
>sockets. For example I might want to plug in an NT named pipe 
>"protocol" (which does not use WinSock). 

BSD sockets are a very strong influence on my thinking. As is XTI and 
WinSock. I am also very aware that ACE has a general purpose IPC 
abstraction. However, the requirements state ( and I agree with them 
) that we should not go done that path. The reason, as I see it is 
that it could easily distract and compromise the production of the 
best possible sockets library

BTW the terminology I use on the whole tends to be BSD because that 
is what most people understand. My preference is for OSI terminology 
which is much cleaner, has better abstractions, and is more exact 
IMO. I don't, on the whole, use it here because I suspect I would end 
up talking to myself ;-).

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