I know I need some sort of friend, but I don't want to friend the
entire class.
I've got a TcpConnection class and it has a state member.
I've got a TcpListener class that accepts connections and creates a
TcpConnectionClass.
The TcpListener class needs to be able to change the state member of
the TcpConnection class, but I don't want anyone else to be able to.
How do I go about that?
This is how I did it:
TcpSvrConnectionListener:
void subscribeForConnections( IfToSvr& ifToSvr );
void unsubscribeForConnections( IfToSvr& ifToSvr );
IfToSvr was nested...
class TcpSvrConnectionListener::IfToSvr
{
public:
virtual void connectedEvt( SOCKET acceptDescriptor ) = 0;
unsigned getPortNum() const{ return portNum_; }
const std::string& getIpAddr() const { return ipAddr_; }
protected: //Operations
//Derivitives to specify the port number
IfToSvr(): portNum_( 0 ), ipAddr_( "" ){ }
IfToSvr( unsigned portNum, const std::string& ipAddr )
: portNum_( portNum ), ipAddr_( ipAddr )
{
}
//won't be deleted through this interface
virtual ~IfToSvr(){}
void setPortNum( unsigned portNum ){ portNum_ = portNum; }
void setIpAddr( const std::string& ipAddr ){ ipAddr_ = ipAddr; }
private:
unsigned portNum_;
std::string ipAddr_;
};
TcpSvrConnectionListener ran in it's own thread (listening),
and subscription routines had to be synchronized, as well
as connectedEvt...
The server itself, well, it just needs to implement the
interface and subscribe. Turned out that I separated
the actual server from connections. The server was, on
connectedEvt, responsible for realizing the actual
connection. The server then used the subject observer
pattern to dispatch the connection to all sockets
interested. The first socket accepting the connection
would take ownership of it, and on it being accepted,
the server would relinquish ownership of the connection.
Connections not accepted within a certain amount of time
was destroyed.
All reading was done by a service class (similar
to what boost does) that monitors for data in a
single thread and dispatches data to the applicable
registrant associated with the socket on which the data
was received (also via interface, the TcpSvrConnection
deriving from it...).
Contrary to what Ian Collins says, in my opinion especially
using blocking sockets complicate user code. KISS, but not
at the expense of usage. I haven't looked at boost sockets
much yet, but I've looked at their usage of IO Completion
Ports, and I like the idea of having a "service" responsible
for listening and connecting(for clients), a "service"
responsible for reading, as not having such a service
complicates user code IMHO. Obviously the service class
will be more complicated, but it has a well defined
responsibility and usage is simple, if not opaque.
You (as user) just create a server, associate a socket. Hookup the
appropriate callbacks to receive data (sending is synchronous), and
wholla. In our implementation, the service class has to exist
prior to this, but enabling of the service classes are done
from a central location. One could instantiate the service classes
when needed. We kept that part simple
and opted for explicit
creation upfront.
We've created interfaces to break dependencies and to communicate
responsibilities of classes in terms of each other.
Good luck
,
Kind regards,
Werner
