Author Topic: connection collections  (Read 4714 times)

Holomorph

  • User
  • *
  • Posts: 32
connection collections
« on: September 05, 2005, 04:01:34 PM »
in my server code, I am keeping a bunch of pointers to connections in a map, the keys being the address of the connection.  This works fine until someone disconnects; in my onDisconnect handling code, I try to remove the key/value pair from the map (via erase) but the problem is I want to get the address by calling conn->getRemoteAddress(true).toString() but the string I get is "invalid address".  So obviously the address is getting invalidated before onDisconnect is being called in the connection listener.  Is there a reason for doing things in this order?  Any suggestions on a better way to manage connections on my server?

Now that I think about it, there is a unique connection listener created for each connection right? So I could store the address in that I suppose.  

Also, the docs for connection listener say "onDisconnect will always be the last event called on this listener, so you can destroy this object after onDisconnect is called" so does this mean the connectionlisteners are not automatically destroyed by gne, but are automatically created? (mb they aren't autocreated and I've forgotten :P)

Bjørn

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
connection collections
« Reply #1 on: September 05, 2005, 04:19:29 PM »
I'm not sure why you should be having to ever deal with addresses.  I believe that getRemoteAddress performs a call to HawkNL, which then performs a call to the operating system.  When onDisconnect is called, the socket is probably already disconnected at the OS layer, so there is no socket to get an address from.

In order to change this behavior, I would need to have to cache the address in the Connection itself.  I don't think it is unreasonable to expect to be able to call getRemoteAddress from onDisconnect, if for no other reason but for log reporting or other "informational output" activities.

The comment about destroying the object in the documentation is outdated.  You are actually creating and assigning the ConnectionListeners in your ServerConnectionListener's onNewConn method, if I remember correctly.  What is misleading about the comment is that you should destroy the object.  Well the documentation was written before GNE moved to smart pointers.  While technically it is correct that the CL can't be destroyed until after onDisconnect (or deregistration of the listener), you don't have to take action on this as the smart pointer system should delete your object when the Connection dies.

Looking at the code, the Connection keeps a strong reference to the EventThread that keeps a strong reference to the ConnectionListener.  This means that a memory leak will occur due to circular reference if the ConnectionListener keeps a strong pointer (sptr) to its Connection.  This is why Connection& is passed into most event methods, so that needing a reference to Connection is not needed.
Gillius
Gillius's Programming http://www.gillius.org/