Sunny
7/6/2004 3:26:00 PM
Hi,
As far as I know, all exposed objects are accessible/exposed using all
registered channels. There is no way to limit this without some custom
sync. You are saying that you can. How? Can you show some sample code?
I''m surprised that you do not see more urls for a given object.
Sunny
In article <74D9E81A-0D71-4E5F-88BF-14C13EAD1D5A@microsoft.com>,
Matt@discussions.microsoft.com says...
> I''ve run into what appears to be a bug in .NET Remoting. It''s a complicated program, so I''ll provide only the details that I think are relevant. If anyone wants more info, please let me know.
>
> In the application, the remoted objects inherit from MarshalByRefObject. They override InitializeLifetimServices and return null (according to the documentation, this should prevent Remoting from disconnecting them after X amount of time). The objects are registered with Remoting via RemotingServices.Marshal. TCP channels are used, and each object is given its own dedicated channel. We specify "0" as the port number and allow it to pick a port that isn''t in use.
>
> Once the object has been registered, we call ChannelServices.GetUrlsForObject with a reference to the object to get the actual Remoting URL including the port number. This URL is then given to clients that need to access the object via a 3rd party object that more or less oversees all remoted objects.
>
> Anyway, when we first get the URL from ChannelServices, we dump that info to a log file. Later, when we unregister the channel and disconnect the object from remoting, we dump the URL again immediately before we begin unregistering things.
>
> Here''s the problem: the URL dumped by ChannelServices the first time does not appear to remain valid throughout the application. While clients can access an object using the initial URL 90% of the time, we''re noticing that some objects no longer respond at their URL''s even though they appear to still be registered. Inspecting the logs, I''ve noticed that the initially generated URL does not match the URL generated by ChannelServices the second time, as in this example:
>
> Generated when we''re marshalling the object -
> tcp://192.168.0.174:1143/788f4751_9f9a_48f4_a111_12a55bd251fe/RemoteObject
> Generated when we''re about to unmarshal the object and clean up its channel -
> tcp://192.168.0.174:1146/788f4751_9f9a_48f4_a111_12a55bd251fe/RemoteObject
>
> As you can see, everything is the same except for the port number. I can''t find anything that justifies this change in ports. If anyone has any suggestions, I''d love to hear them.
>