Re: sockets Interface for address class

From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-02-27 15:23:12

--- In boost_at_y..., Iain.Hanson_at_u... wrote:
>      The following is the interface for a unicast address in psudo 
code. 
>      I'm not that enamoured by the names of the mutator and 
accessor 
>      methods so if anyone has better suggestions they would be 
welcome. I'd 
>      appreciate comments, is this interface complete ? is it too 
fat? etc.
>      
>      
>      class address
>      {
>      public:
>      
>      // none of the following ctors need marshalling address ( );
>      
>      // sockaddr_in or in6
>      address ( protocol_address_representation & Address );
>      
>      address ( address & Rhs );
>      
>      address & operator= ( address & Rhs );
>      
>      // the following two need marshalling 
>      address ( const char * Address , port_type Port = any_port );
>      
>      explicit address ( const std::string & Address , 
>      port_type Port = any_port );
>      
>      // mutators
>      reset ( const char * Address , port_type Port );
>      
>      reset_address ( const char * Address  );
>      
>      reset_port (  port_type Port );
>      
>      
>      // accessors
>      const char * c_str ( ) const;
>      
>      const port_type port ( )
>      
>      
>      };

I have a few suggestions:
- You missed the const modifiers in a few places
- 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)
- I think it would make sense to provide conversion to an unspecified 
"native" type (such as sockaddr)
- We also need a few special pre-deined IP addresses (like loopback).

With these things in mind here is my take on it:

class inet_address {
public:
  typedef uint16_t port_type;
  static const port_type any_port = 0;

  // could be `sockaddr'
  typedef IMPL_DEFINED native_type;

  inet_address();

  // Dotted-decimal IP addres + port:
  //  111.222.333.123:80   or
  //  111.222.333.123 <-- assume ANY port
  inet_address( const char *full_addr );
  inet_address( const std::string &full_addr );

  inet_address( const std::string &ip_addr, port_type port );
  inet_address( const native_type & );

  // Special predefined addresses
  static inet_address loopback( port_type port = any_port );
  static inet_address any( port_type port = any_port );

  // These accept the dotted-decimal notation + port
  // or hostname + port, in which case they use the
  // more generic name resolution service:
  //  111.222.333.123:80
  //  name.com:80
  //  name.com  <-- assume ANY port
  static inet_address primary( const std::string &full_addr );
  static inet_address primary( const std::string &ip_addr,
     port_type port );

  std::string str() const;

  std::string ip_addr() const;
  void ip_addr( const std::string & );

  port_type port() const;
  void port( port_type );

  const native_type &native() const;

  // Return non-zero if address is valid
  operator const void *() const;

  // (Copy & assignment)
  // (Relation operators)
  // (Destructor)

private:
  // ...
};

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

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?

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

Your thoughts?
D.P.

>      
>      plus ostream and istream operators
>      
>      
>      /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.