[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Stale Clients

Phil Jones

8/15/2004 12:45:00 AM

I have a situation where I'm attaching to events on the client to a Remote
(singleton) object on the server.

The problem is if I close the client, the delegate reference still exists
within the server object, and when the event fires, and the server object
attempts to process all of the event delegates in it's list - it fails
(SocketException: No Connection) when processing the delegate of the closed
client.

I wonder: what is the correct or generally accepted approach to this
scenario?
Should clients un-register their events before closing (if so, what if the
client crashes)?
Or, is there a common design pattern on for the server??

I can error handle this on the server - but I was just checking if there was
a "YOU SHOULD BE DOING THIS" solution here.

Cheers everyone!
2 Answers

Sam Santiago

8/15/2004 3:38:00 AM

0

I vote for the client unregistering when it is able to shut down
appropriately. The server should also be implemented with some defensive
programming to catch the error for disconnected clients and remove that
delegate from the collection of delegates to avoid future troubles. Instead
of simply raising the event the server object should manually invoke each
registered client because if one of clients disconnects and raises an
exception the remainder of the registered clients would not be called.
Check out this article, it has an example at the bottom.

Implementing Callbacks with a Multicast Delegate
http://msdn.microsoft.com/msdnmag/issues/03/01/basic...


Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago@n0spam-SoftiTechture.com
http://www.SoftiTe...
_______________________________
"Phil Jones" <phil_newsgroup@hotmail.com> wrote in message
news:uYQo9%23lgEHA.384@TK2MSFTNGP10.phx.gbl...
> I have a situation where I'm attaching to events on the client to a Remote
> (singleton) object on the server.
>
> The problem is if I close the client, the delegate reference still exists
> within the server object, and when the event fires, and the server object
> attempts to process all of the event delegates in it's list - it fails
> (SocketException: No Connection) when processing the delegate of the
closed
> client.
>
> I wonder: what is the correct or generally accepted approach to this
> scenario?
> Should clients un-register their events before closing (if so, what if the
> client crashes)?
> Or, is there a common design pattern on for the server??
>
> I can error handle this on the server - but I was just checking if there
was
> a "YOU SHOULD BE DOING THIS" solution here.
>
> Cheers everyone!
>
>

Phil Jones

8/15/2004 5:29:00 AM

0

Sweet - thanks for the advice : that multi-cast delegate code was what I was
looking for too.

Cheers - P



"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:%23VVNSlngEHA.3964@TK2MSFTNGP12.phx.gbl...
> I vote for the client unregistering when it is able to shut down
> appropriately. The server should also be implemented with some defensive
> programming to catch the error for disconnected clients and remove that
> delegate from the collection of delegates to avoid future troubles.
Instead
> of simply raising the event the server object should manually invoke each
> registered client because if one of clients disconnects and raises an
> exception the remainder of the registered clients would not be called.
> Check out this article, it has an example at the bottom.
>
> Implementing Callbacks with a Multicast Delegate
> http://msdn.microsoft.com/msdnmag/issues/03/01/basic...
>
>
> Thanks,
>
> Sam
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTe...
> _______________________________
> "Phil Jones" <phil_newsgroup@hotmail.com> wrote in message
> news:uYQo9%23lgEHA.384@TK2MSFTNGP10.phx.gbl...
> > I have a situation where I'm attaching to events on the client to a
Remote
> > (singleton) object on the server.
> >
> > The problem is if I close the client, the delegate reference still
exists
> > within the server object, and when the event fires, and the server
object
> > attempts to process all of the event delegates in it's list - it fails
> > (SocketException: No Connection) when processing the delegate of the
> closed
> > client.
> >
> > I wonder: what is the correct or generally accepted approach to this
> > scenario?
> > Should clients un-register their events before closing (if so, what if
the
> > client crashes)?
> > Or, is there a common design pattern on for the server??
> >
> > I can error handle this on the server - but I was just checking if there
> was
> > a "YOU SHOULD BE DOING THIS" solution here.
> >
> > Cheers everyone!
> >
> >
>
>