Creating a Server Application using tidtcpserver

[JIMSMITH 1]

I want to create a server application that can handle multiple connections, even from the same computer.  An important point is that if the client application disconnects from the server I need to be able to reconnect the application to the object in the server for continuity.  I can handle the reconnect, I think, but need some assistance in associating the the context with the context or object from the original connection.  When does the context get destroyed. Many question and I need help finding answers.  Seems like I would have to keep a token or something to send to the server to recognize the repetitious connection for each application connected to the server.  Am I correct in this assumption?  I wonder how I know the connection that was disconnected if the network connection drops.  Should I launch an anonymous thread to read and process the message from the execute event on the server? I am continuing m investigation.

 

 

 

Edited 19 hours ago by JIMSMITH

[Remy Lebeau 1520]

13 hours ago, JIMSMITH said:

I want to create a server application that can handle multiple connections, even from the same computer.

TIdTCPServer handles that just fine.

13 hours ago, JIMSMITH said:

An important point is that if the client application disconnects from the server I need to be able to reconnect the application to the object in the server for continuity.  I can handle the reconnect, I think, but need some assistance in associating the the context with the context or object from the original connection.

It is your responsibilility for tracking your objects and making sure they stick around between (re-)connects. But as for the actual association, TIdTCPServer provides two options:

• TIdContext has a public Data property, which you can use to associate a client with your custom data.
• You can derive a custom class from TIdServerContext, add whatever you want to it, and then assign that class type to the TIdTCPServer.ContextClass property before activating the server.  Then, in the server's events, you can type-cast the provided TIdContext object to your custom class.

13 hours ago, JIMSMITH said:

When does the context get destroyed.

When the client disconnects from the server an the owning thread is stopped.

13 hours ago, JIMSMITH said:

Seems like I would have to keep a token or something to send to the server to recognize the repetitious connection for each application connected to the server.  Am I correct in this assumption?

Most likely, yes.  When a client connects, you can issue it a token.  If the client reconnects, it can ask to reuse that same token.  When the client is finished with the token, the server can invalidate it.

 

Unless you have some other way to associate each client with a given resource, such as with a unique login userid, etc.

13 hours ago, JIMSMITH said:

I wonder how I know the connection that was disconnected if the network connection drops.

The server will tell you in the OnDisconnect event.

13 hours ago, JIMSMITH said:

Should I launch an anonymous thread to read and process the message from the execute event on the server?

That is not necessary.  The server is already running the client interaction in its own thread.  If a client disconnects for any reason, the OnDisconnect event will be triggered, before the context is destroyed.

Edited 16 hours ago by Remy Lebeau

[JIMSMITH 1]

8 minutes ago, Remy Lebeau said:

TIdTCPServer handles that just fine.

It is your responsibilility for tracking your objects and making sure they stick around between (re-)connects. But as for the actual association, TIdTCPServer provides two options:

• TIdContext has a public Data property, which you can use to associate a client with your custom data.
• You can derive a custom class from TIdServerContext, add whatever you want to it, and then assign that class type to the TIdTCPServer.ContextClass property before activating the server.  Then, in the server's events, you can type-cast the provided TIdContext object to your custom class.

When the client disconnects from the server an the owning thread is stopped.

Most likely, yes.  When a client connects, you can issue it a token.  If the client reconnects, it can ask to reuse that same token.  When the client is finished with the token, the server can invalidate it.

 

Unless you have some other way to associate each client with a given resource, such as with a unique login userid, etc.

The server will tell you in the OnDisconnect event.

That is not necessary.  The server is already running the client interaction in its own thread.  If a client disconnects for any reason, the OnDisconnect event will be triggered, before the context is destroyed.

I am starting to work on this.  I always have a high level of confidence in your responses on any topic.  Thank you very much.

Edited 15 hours ago by JIMSMITH

[JIMSMITH 1]

2 hours ago, JIMSMITH said:

I am starting to work on this.  I always have a high level of confidence in your responses on any topic.  Thank you very much.

Remy are there any good articles on the TIdContext and the  TIdServerContext  and how to use them and when to use one over the other properly?

 

Thanks in advance.

[Remy Lebeau 1520]

29 minutes ago, JIMSMITH said:

Remy are there any good articles on the TIdContext and the TIdServerContext and how to use them and when to use one over the other properly?

No, sorry.

 

The simplest approach is to just use TIdContext.Data, it is an opaque Pointer, you can assign whatever you want to it.

 

Deriving from TIdServerContext offers more flexibility, as you can define any extra fields, properties, and methods that you want.

[Olli73 6]

10 hours ago, Remy Lebeau said:

The simplest approach is to just use TIdContext.Data, it is an opaque Pointer, you can assign whatever you want to it.

Isn't it so that the IdContext is freed on connection loss and so I have no reference anymore to my data on reconnect?

 

Then he could save the data reference in a dictionary (do not forget to use a locking mechanism) with IP address or any Unique Client ID as key and restore the data reference on reconnect.