.NEt remote event and DNS reverse lookup

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • schaf

    .NEt remote event and DNS reverse lookup

    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

    #2
    Re: .NEt remote event and DNS reverse lookup

    On Sep 13, 5:35 am, schaf <sc...@2wire.ch 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 ?
    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>)

    Comment

    • Chris Shepherd

      #3
      Re: .NEt remote event and DNS reverse lookup

      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.

      Comment

      • Chris Shepherd

        #4
        Re: .NEt remote event and DNS reverse lookup

        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.

        Comment

        • schaf

          #5
          Re: .NEt remote event and DNS reverse lookup

          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
          RemoteDelegateO bject. 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.

          Comment

          • Chris Shepherd

            #6
            Re: .NEt remote event and DNS reverse lookup

            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
            RemoteDelegateO bject. 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.

            Comment

            • Doug Semler

              #7
              Re: .NEt remote event and DNS reverse lookup

              "Chris Shepherd" <chsh@nospam.ch sh.cawrote in message
              news:e9zfmZh9HH A.4752@TK2MSFTN GP04.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
              >correspondin g 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:


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

              Comment

              • Chris Shepherd

                #8
                Re: .NEt remote event and DNS reverse lookup

                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.

                Comment

                • Doug Semler

                  #9
                  Re: .NEt remote event and DNS reverse lookup

                  On Sep 13, 12:02 pm, schaf <sc...@2wire.ch wrote:
                  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
                  RemoteDelegateO bject. 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...)

                  Comment

                  Working...