You don't say, but I assume you are using TCP/IP.  If so, the network
protocol itself only supports an IP address and port number for
identifying an endpoint.

First thing is that you have not been very clear about what even the
"host" and "port" items indicate for the connection.  Are you specifying
the server's IP address and port number?  Or is the client supposedly
providing its own IP address and port number to the server?

Your other comments seem to imply that these are actually the server IP
address and port, but if that's the case then it's not really true that
the server "requires three inputs".  The server itself only requires the
identification number.  It's the local socket API that requires the
other two (so that it can contact the server for you).

As far as the identification number goes, that must be part of your
application-level protocol.  Since the protocol presumably requires a
variety of other things implemented as well to support it, then the
place for that identification number is wherever you implement the rest
of the application protocol.

That's because the network protocol doesn't know anything about your
application protocol.  You tell the network API the server's IP address
and port number.  It then connects you to the server, and the rest is up
to you.

IMHO, you need a class that implements the application protocol.  This
class would _contain_ a socket, but would not inherit the Socket class.
 The socket is a necessary part of the implementation of the protocol,
but the application protocol itself does not derive from the socket, so
the class shouldn't inherit the socket.

Note that this is a conceptual opinion.  You could easily view the
situation differently, asserting that since your application protocol is
in fact implemented on top of the underlying network protocol, that your
application protocol class should inherit the underlying network API
class.  IMHO, the main problem with this is that your application
protocol is unlikely to need, or even want, to expose the underlying
network API.

From the application's point of view, it should not care at all that
the application protocol is implemented on top of a network protocol, so
inheriting the class is not only not useful, it prevents your
application protocol class from fully encapsulating and hiding the
underlying i/o implementation.  By doing this, your application protocol
can be made to work on any number of i/o APIs, not just the Socket
class.  In that case, you would make a base abstract class that at least
describes the required public methods, if not implements some of the
behavior based on some basic assumed behavior for the i/o API, and then
you can create i/o-API-specific classes inheriting the base application
protocol class.

You may in fact never have a need to do any of this latter stuff.  But
IMHO the potential for that illustrates why I feel that the application
protocol isn't really inherited from the network protocol.

Pete

I assume you mean System.Net.Sockets.Socket here. But for inspiration,
there is already something in the framework which does what you
consider: System.Net.Sockets.TcpClient is what Peter suggests, a class
that implements the application protocol (in a way) and contains a
Socket. You could look at TcpClient and see if that resembles what you
want to do. (Or, if you're always going to use TCP/IP, you might want
to use a TcpClient in your application instead of a Socket.)

Thanks for the suggestions.  I was wrong about the requirement of three
inputs -- the server can only take two, as you've said, because TCP/IP only
takes two.  The third element is sent after a successful connection.