Hi Chris!
Thanks for your response!
> Exactly how is your Remoting accomplished? TCP? HTTP?
TCP
> Are you using IIS to host the remoting service?
NO
> More information will make it much simpler to answer your question.
So we are using the .NET Remoting events with a shared callback
delegate. A class on the client derives from the shared class
RemoteDelegateObject. This class has a function (event handler) which
has the same interface like the remote callback delegate. This
function will be assigned to the event on the server. (like Ingo
Rammer recommend)
Analysing the communication shows a DNS reverse lookup right after the
server fires this remote event the first time. So just after starting
the service. If the service is running and I call the same function, I
will not get this DNS reverse lookup.
Why? Is .NET caching the network information ?
Hope you can help me.
Chris Shepherd - 13 Sep 2007 18:49 GMT
>> More information will make it much simpler to answer your question.
> So we are using the .NET Remoting events with a shared callback
[quoted text clipped - 9 lines]
> will not get this DNS reverse lookup.
> Why? Is .NET caching the network information ?
In all likelihood yes, most DNS requests are temporarily cached, either
by your PC (very short duration) or by the DNS server on the LAN
(duration up to the expiry of the DNS record, normally).
As to why it is doing it, I'm going to guess it's related to the fact
that it has the ability to limit channel access to specific hosts. It
may not be anything you can suppress (I can't find anything on it in the
docs or via google).
How long is it taking on average to do the DNS query? It may be the real
problem lies elsewhere.
Chris.
Doug Semler - 14 Sep 2007 16:51 GMT
> Hi Chris!
> Thanks for your response!
[quoted text clipped - 23 lines]
>
> Hope you can help me.
Regardless of what's going on behind the scenes, you need to be aware
of some potential pitfalls of switching the roles of the client and
server (since when you fire an event, the server is becoming a client
and the client is becoming a server). It introduces a lot of
potential issues (one that we ran into was with multihomed systems and
the client sending the wrong IP address and/or unresolvable hostname
to the server with which it was communicating). That being said, is
there any particular reason that you are using an event fire from the
server to client when the remote calculation is completed rather than
allowing the client to control whether the function is called
synchronously or asynchronously? Also, ensure that your remote events
are set up properly. It has to do with what happens if the event
can't fire over the channel and the non-removal of the remote event
handler on the server side...I think Ingo Rammer's book on
Advanced .NET Remoting goes into this (and I'm sure there are sites
out there that cover it as well...)