EldoS | Feel safer!

Software components for data protection, secure storage and transfer

OnDisconnect - identify which client disconnected

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#10556
Posted: 07/10/2009 09:44:34
by David Perkins (Standard support level)
Joined: 12/03/2008
Posts: 17

In my server application I maintain a list of connected clients using GetMessageSource as the main identifier. When I receive an OnDisconnect event, I need to remove the client from my list, however, I cannot figure out how to do this just using the information passed in from with the OnDisconnect event. Is this possible?
#10557
Posted: 07/10/2009 12:09:07
by xion_more  (Basic support level)
Joined: 05/05/2009
Posts: 19

There is Destroy method in Messenger class. It is use to dispose messages in a queue. I dont know much details about this. Try to use this or wait for Eugene . He will recommend you better. Till the try to read the source or API provided in that library.

Thanks.
#10560
Posted: 07/11/2009 03:05:24
by Eugene Mayevski (EldoS Corp.)

GetMessageSource is used for only one purpose - to send a new message to the sender of the received message (this might be needed, for example, when processing of the original message takes some significant time.
GetMessageSource must not be used for any other purpose.

Now about the list of "connected clients". MsgConnect has connectionLESS message-based architecture. This means that the clients should register and unregister themselves on the server using messages, and if the client doesn't confirm it's registered status within some time, the server should treat the client as disconnected.


Sincerely yours
Eugene Mayevski
#10564
Posted: 07/11/2009 06:54:43
by David Perkins (Standard support level)
Joined: 12/03/2008
Posts: 17

Using MsgConnect we have implemented an asynchronous Request-Response system, where by clients can request some data and some time later (seconds, minutes) the data is returned. For this we use the MessageSource which is stored in our list of 'connected clients'.

We've also implemented a publish subscribe mechanism whereby clients may subscribe to various messages

Typically, clients connect, Login/register and then subscribe to a number of messages. Our connected clients can issue a 'Log off' message, but for unexpected disconnections we'd like to know which client was disconnected so that we're not sending published messages to a 'message source' that is no longer connected.

Is it possible to check whether a message source string is still connected? Or, would we have to poll every client to see whether they're still connected?
#10565
Posted: 07/11/2009 08:42:54
by Eugene Mayevski (EldoS Corp.)

Quote
David Perkins wrote:
Typically, clients connect, Login/register and then subscribe to a number of messages. Our connected clients can issue a 'Log off' message, but for unexpected disconnections we'd like to know which client was disconnected so that we're not sending published messages to a 'message source' that is no longer connected.


In many cases if the client reconnects, it will maintain the same address identifier, returned via GetMessageSource. This means that even if the client disconnects and reconnects later (for example, if it disconnects due to Inactivity Timeout), you will get the same GetMessageSource. So removal of the address identifier from your list doesn't always make sense. Next, it would be better to remove the entries after certain period if the client didn't confirm it's connected state using so-called keep-alive message whose only purpose is to keep logical connection active.


Sincerely yours
Eugene Mayevski
#10566
Posted: 07/11/2009 09:29:07
by David Perkins (Standard support level)
Joined: 12/03/2008
Posts: 17

OK, Understood. After a disconnect I plan to place their 'client connection' class into a 'Disconnected pending removal' state so that if the client reconnects within a brief period of time we still retain their settings and subscriptions. If they file connect after a certain amount of time, all 'client connection' classes with a status of 'Disconnected pending removal' are removed. This is what lead to the original problem, associating an OnDisconnect with a client class.

If a client unexpectedly disconnects and does not reconnect, will attempting to use PostMessage to that connection significantly affect receiving and transmitting other messages?

Keep-alive messages: Using our list of 'Message source' identifiers (some of which may now be disconnected), should I just use PostMessage be ready to catch an exception if I try to send to a message source that has just disconnected?

What is a typical keep-alive period in your experience?
#10568
Posted: 07/12/2009 02:11:52
by Eugene Mayevski (EldoS Corp.)

Quote
David Perkins wrote:
OK, Understood. After a disconnect I plan to place their 'client connection' class into a 'Disconnected pending removal' state so that if the client reconnects within a brief period of time we still retain their settings and subscriptions. If they file connect after a certain amount of time, all 'client connection' classes with a status of 'Disconnected pending removal' are removed. This is what lead to the original problem, associating an OnDisconnect with a client class.


You can keep the same scheme with the approach I offered: if the client doesn't send a keep-alive within a couple of minutes (for example), you put it to the pending removal list, and remove it after, say, 5 minutes.

This is logical disconnection in opposite to "physical" (in our case TCP layer) one.

Quote
David Perkins wrote:
If a client unexpectedly disconnects and does not reconnect, will attempting to use PostMessage to that connection significantly affect receiving and transmitting other messages?


The messages will stay in the outgoing queues for some time, then they will be discarded. Of course, if you have thousands of pending messages in the queue, this will affect performance. For small number of "orphan" messages (say 10-15% of the queue), this will not play big role.

Quote
David Perkins wrote:
Keep-alive messages: Using our list of 'Message source' identifiers (some of which may now be disconnected), should I just use PostMessage be ready to catch an exception if I try to send to a message source that has just disconnected?


PostMessage is asynchronous and doesn't throw exceptions. The posted messages are thrown away if they can't be delivered. If you want other behaviour, use SendMessageTimeout (synchronous) or SendMessageTimeoutCallback (asynchronous, with notifications).

Quote
David Perkins wrote:
What is a typical keep-alive period in your experience?


1-2 minutes is usually fine, but this depends on the amount of messages your server sends and receives. You would need to find proper balance between "extra" keep-alive messages and extra messages sent to the clients, which are disconnected.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.

Reply

Statistics

Topic viewed 5099 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!