.NEt remote event and DNS reverse lookup

[schaf]

Hi NG!
I have a problem in my remote application.
After calling a remote function the calculation will be done by the
service. The calculation result will be sent to the caller (client)
via remote event.
The following behavior can be observed:

1.) Right after the start of the server the first response via remote
event will take a long time.
2.) Calling the same function a second time will not be a problem.
3.) If I enter the IP address of the client (caller) into the host
file, the first call will not take this long time.
So does .NET remoting use DNS reverse look-up to obtain the client
address?
If yes, is it possible to change this behavior or do I have to permit
DNS reverse look-up ?
Thanks and Regards
Marcel

[Doug Semler]

On Sep 13, 5:35 am, schaf <[e-mail]:

Hi NG!
I have a problem in my remote application.
After calling a remote function the calculation will be done by the
service. The calculation result will be sent to the caller (client)
via remote event.
The following behavior can be observed:

1.) Right after the start of the server the first response via remote
event will take a long time.

2.) Calling the same function a second time will not be a problem.

3.) If I enter the IP address of the client (caller) into the host
file, the first call will not take this long time.

So does .NET remoting use DNS reverse look-up to obtain the client
address?
If yes, is it possible to change this behavior or do I have to permit
DNS reverse look-up ?

I think you have it backwards. The IP address is the final resolution
level, not the computer name. When you pass it a computer name, the
system must do an address resolution, NOT a DNS reverse lookup. A DNS
reverse lookup is when you give it the IP address and want to get the
corresponding machine name(s). The reason it is "faster" when you
give it the IP address is because it DOESN'T have to go to the address
resolution; the IP address is already assumed to be resolved (that
doesn't mean it's not a BAD IP address, just that you have an IP
address). The results of a lookup are cached, or saved locally so
that the DNS service doesn't have to be called EVERY time you want an
address. That's why it doesn't take as long the second time around.
I don't remember the caching rules offhand, but I think the default
DNS cache TTL is actually set by the server after a query...

IP Addressing can be thought of like a telephone system (generally).
Each person (computer) has a particular phone number (IP Address) that
it can be contacted on. If you already have the phone number (IP
Address) you don't have to do anything, you just dial it. But if you
don't have the phone number (IP Address), you have to look it up in
the phone book (DNS Service). You find the name and now have the
number. There also exists a REVERSE phone book (reverse DNS lookup)
that allows you to find out the name of the person (computer) that is
at a particular phone number (IP Address). (for pedants out there,
YES I know this is simplified but is a fairly decent analogy for a non
ip guru <g>)

[Chris Shepherd]

Doug Semler wrote:

I think you have it backwards. The IP address is the final resolution
level, not the computer name. When you pass it a computer name, the
system must do an address resolution, NOT a DNS reverse lookup. A DNS
reverse lookup is when you give it the IP address and want to get the
corresponding machine name(s).

The OP does not have it backwards. What he explained is exactly what a
reverse lookup is.

Chris.

[Chris Shepherd]

schaf wrote:

Hi NG!
I have a problem in my remote application.
After calling a remote function the calculation will be done by the
service. The calculation result will be sent to the caller (client)
via remote event.
The following behavior can be observed:

1.) Right after the start of the server the first response via remote
event will take a long time.

2.) Calling the same function a second time will not be a problem.

3.) If I enter the IP address of the client (caller) into the host
file, the first call will not take this long time.

So does .NET remoting use DNS reverse look-up to obtain the client
address?
If yes, is it possible to change this behavior or do I have to permit
DNS reverse look-up ?
Thanks and Regards
Marcel

Exactly how is your Remoting accomplished? TCP? HTTP?
Are you using IIS to host the remoting service?

More information will make it much simpler to answer your question.

Chris.

[schaf]

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]

schaf wrote:

>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 ?

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]

"Chris Shepherd" <ch**@nospam.chsh.cawrote in message
news:e9**************@TK2MSFTNGP04.phx.gbl...

Doug Semler wrote:

>I think you have it backwards. The IP address is the final resolution
level, not the computer name. When you pass it a computer name, the
system must do an address resolution, NOT a DNS reverse lookup. A DNS
reverse lookup is when you give it the IP address and want to get the
corresponding machine name(s).

The OP does not have it backwards. What he explained is exactly what a
reverse lookup is.

Chris.

Huh? The OP asked why it was slower when he used a computer name rather
than an IP address. His "problem" is completely related to how DNS queries
are made and how fast they are and how they are cached. Nothing about
reverse lookups. A reverse lookup is NOT looking up in a hosts file. A
reverse lookup is getting the hostname from IP address. NOT what he was
describing. There is no reverse lookup going on. The delay is in the
transfer of information from the DNS service to the local machine. Windows
first checks the hosts file before it goes out to the "outside world". It
is faster when there is no need to go to the outside world. Regardless of
whether the query is IP to hostname or hostname to IP.

If you want more information on how and when a windows box looks up a
computer name to resolve an IP address (and the cache time to live by the
way), go to:
http://technet.microsoft.com/en-us/l.../bb727005.aspx

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

[Chris Shepherd]

Doug Semler wrote:

Huh? The OP asked why it was slower when he used a computer name rather
than an IP address. His "problem" is completely related to how DNS
queries are made and how fast they are and how they are cached. Nothing
about reverse lookups. A reverse lookup is NOT looking up in a hosts
file. A reverse lookup is getting the hostname from IP address. NOT
what he was describing.

Yes, it is what he was describing. The *server* is being slow when
answering client connections because the *server* is looking up the
*client's ip address* in an attempt to resolve it to a hostname.

I see from your other post that you misread the OP, so the point is moot.

Chris.

[Doug Semler]

On Sep 13, 12:02 pm, schaf <[e-mail]:

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.

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...)