Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Server "connection" object/variable when disconnecting from server side
#2
(10-28-2020, 10:14 AM)noname007 Wrote: I intend to build a TCP server able to serve lots of clients. Because of the port depletion in Windows (and for some other reasons), I use disconnect from the server side, not from the client side.

Port exhaustion would not affect the server, only clients.  And if clients are running out of ports, they are making too many connections in a short amount of time, so you should be reusing connections instead of dropping them.

(10-28-2020, 10:14 AM)noname007 Wrote: The steps are like this: client connects, client requests data, server answers with data, client requests disconnect, server disconnects.

That is a very unusual design if you are not sending multiple requests per connection.  In a 1-request-per-connection scenario, can you include the disconnect request in the initial data request (like HTTP does), or just disconnect blindly without waiting for the client to request it?

(10-28-2020, 10:14 AM)noname007 Wrote: The OnExecute in server does not process the requests, but it adds them to a queue, from which they are retrieved almost immediately by the queue processing thread, and then processed in 4 - 64 parallel task/job processing threads.

What if the client disconnects before the queued request is processed?  Do you remove the request from the queue?  Or let it fail when it tries to write back to a dead connection?

(10-28-2020, 10:14 AM)noname007 Wrote: The problem I encountered is that many times (not always, but quite frequently) the "connection" object I saved from within the OnExecute (AContext.Connection) and stored into the queue is no longer the same when the task or job is retrieved from the queue. The connection object now points to a different connection that may have been already closed.

Indy does not reuse Connection objects.  A new Connection object is created before a client is accepted, and is then destroyed after that client disconnects.  Most likely, you are storing a pointer to a Connection object is has been destroyed before you are able to access it, so that memory address is invalid, or worse has been reused for a new object elsewhere (a different Connection, or something else completely unrelated), either way causing undefined behavior in your code.

(10-28-2020, 10:14 AM)noname007 Wrote: How can I save from within OnExecute a persistent "connection" that can be used even seconds later, outside the OnExecute event, if the disconnections occur on the server side and not on the client side?

Don't store a pointer to the Connection object.  Store a pointer to the Context object instead, and then validate that object is still present in the server's Contexts list before using its Connection.  Alternatively, store per-Context identification info (client ID, etc) and then search the Contexts list for that ID when needed.

Either way, you have a race condition, if the client disconnects while you are using the Connection.  Unless you keep the server's Contexts list locked while sending responses, which I don't suggest. Worse case, you may have to just store the underlying SOCKET itself and write to it directly, and just let the OS fail if the SOCKET is closed.  That will work on Windows, at least, where SOCKETs are unique kernel objects.  Not so much on Posix systems, where sockets are file descriptors that can be reused.

Reply


Messages In This Thread
RE: Server "connection" object/variable when disconnecting from server side - by rlebeau - 10-28-2020, 07:09 PM

Forum Jump:


Users browsing this thread: 2 Guest(s)