Archived

This forum has been archived. Please start a new discussion on GitHub.

About ice_ping()

When the client(or the server) is not online ,which other method can let the server(or then client ) know?
Do not use ice_ping() function.

Comments

  • I'm not quite sure what you mean here.
    Are you asking for a basic connectivity test?
    If so, ice_ping() is what you want. It establishes whether the target object can be reached and, if so, completes normally. Otherwise, if the target object can't be reached, the exception that is thrown tells you something about the reason for the failure such as

    - ConnectFailedException: the connection couldn't be established, for example, because the domain name in the proxy couldn't be resolved, or because no route to the host exists.

    - ConnectionRefusedException (as of Ice 1.4.0, coming shortly): the server is up, but actively replied with an ICMP reply saying that nothing is listening at the target port.

    - ObjectNotExistException: the server is up and could be reached, but no servant could be located with the object identity of the proxy.

    - etc.


    So, for a basic sanity check, ice_ping() is your friend. If you want to dig deeper, you can use TCP/IP tools, such as traceroute and dig, to find out why things are not working as expected.

    Cheers,

    Michi.
  • That is ,the ice_ping() is my one and only choice,besides the socket level?

    BTW, When can I use the ice 1.4 ?
  • Hmmm... Is there something you want that ice_ping() won't do for you?

    We'll release Ice 1.4.0 next week.

    Cheers,

    Michi.
  • One thing that we noticed is that the ObjectNotExistException is not thrown when using oneways which makes sense in hind-sight, but wasn't obvious at first.

    I'm not sure, it has been a while, but I don't believe that ice_ping() was throwing an exception when a oneway was used too.

    What we've done in our application to test basic connectivity is to run a scrubber thread that tests connectivity at some time threshold using ice_ping(). If an exception is thrown we then clean-up the session.

    When the connection was lost we were able to see that there were low-level socket exceptions that Ice was getting, but we were unable to get notification of. At the time it seemed like the most straiight-forward implementation, if it existed, might have been to create a callback that we could give to Ice so we could get notification as soon as a ObjectNotExisit or ConnectionLost or simliar exception was created.

    Regards --Roland
  • Originally posted by rhochmuth
    One thing that we noticed is that the ObjectNotExistException is not thrown when using oneways which makes sense in hind-sight, but wasn't obvious at first.

    It's in the manual, on page 428:
    Of course, this means that a oneway invocation is unreliable: it may never be sent (for example, because of a network failure) or it may not be accepted in the server (for example, because the target object does not exist). If anything goes wrong, the client-side application code does not receive any notification of the failure; the only errors that are reported to the client are local errors that occur on the client side during call invocation (such as failure to establish a connection, for example).
    I'm not sure, it has been a while, but I don't believe that ice_ping() was throwing an exception when a oneway was used too.

    That's right. Provided the connection can be opened on the client side and the request handed over to the local kernel for transmission, there won't be an exception on the client side. Basically, with a oneway proxy, ice_ping() tells you that a connection could be established to the server, but no more.
    What we've done in our application to test basic connectivity is to run a scrubber thread that tests connectivity at some time threshold using ice_ping(). If an exception is thrown we then clean-up the session.

    When the connection was lost we were able to see that there were low-level socket exceptions that Ice was getting, but we were unable to get notification of.

    Hmmm... Do you have more detail on this? As a rule, the run time will catch socket exceptions and retry the invocation if it is possible to do so without violating at-most-once semantics. Otherwise, or if the retry fails, the exception is propagated to the application.

    Cheers,

    Michi.
  • It's better that the ice(communicator) can tell me the proxy is in a state of unconnection ,on ice(communicator)'s initiative.
    Instead of by call ice_ping() in my specially codes .
  • Originally posted by level
    It's better that the ice(communicator) can tell me the proxy is in a state of unconnection ,on ice(communicator)'s initiative.
    Instead of by call ice_ping() in my specially codes .

    Hmmm... Adding an API call for this wouldn't be all that useful. For one, for UDP proxies, no connection concept applies. And, with ACM (Automatic Connection Management), there is potential race condition because, if you ask a proxy whether it is connected, and the answer is "yes", it may be disconnected the very next moment.

    What exactly are you trying to do that ice_ping() won't do for you?

    Cheers,

    Michi.
  • I just care the ice_ping()'s efficiency.I consider the ice_ping() is equal to the DOS command ping.exe?
    I am afraid of the 10000 or more client call ice_ping() that the sever can not do respond.

    And if you use soket , the Closesocket function will tell you the unconnetion now?
  • Originally posted by level
    I just care the ice_ping()'s efficiency.I consider the ice_ping() is equal to the DOS command ping.exe?
    I am afraid of the 10000 or more client call ice_ping() that the sever can not do respond.

    There is no reason why a client would call ice_ping(), as a rule. The call is provided simply as a diagnostic tool, so you can do a basic connectivity test. A normal client won't call ice_ping() at all -- instead, it will simply start talking to the objects it wants to use.

    The cost of ice_ping() is the same as invoking an operatio with void return type and no parameters, that is, the cost is the same as for a simply RPC.
    And if you use soket , the Closesocket function will tell you the unconnetion now?

    I don't see why you would care about the connection in a client. The Ice run time automatically establishes connections as they are needed and tears them down again when they are no longer needed. The programming model is connectionless -- the run time manages connections for clients transparently.

    Cheers,

    Michi.
  • This is going to be hard to describe and hopefully I won't confuse this duscussion with the original posters. We call ice_ping to test connectivity, so I'll try and state some of the reasons why we did this, but I probably won't get this right the first time around.

    We use oneways for many of our invocations mainly for performance. We have a p2p application in that both ends are clients and servers. I'll call one end the Receiver and the other end the Sender which is the terminology we use.

    The Receiver invokes requestUpdate(). Then the Sender does a series of putUpdates() and finally an endUpdate(). Then the Receiver initiates another requestUpdate().The main point,here is that the Sender only does something in response to a Receiver request. So if the Receiver is killed I believe what we observed was a Sender waiting for a new request. We would never see the ConnectionLost exception since there never was another method invocation, such as putUpdate(), on the Sender side.

    I'm a little hazy on what happened to the socket exceptions in the Ice run time. I thought Ice caught them and did not propogate them up the call stack, but I might be mistaken. The other possiblity, is that they were propogated, but they weren't in a good location for us to use.

    So that was the first reason for using and ice_ping(). Our Sender allocates a lot of memory per Receiver and we didn't want to keep this around when the Receiver was killed. A Ice invocation never occured on the Sender side in this case because it needed to be initiated by the Receiver. The scrubber thread that performed ice_pings at 1-5 sec intervals that I mentioned earlier seemed like a good way to test whether the Receiver was alive.

    The second reason was that since we use oneways the ObejctNotFound exception was not thrown. So in this case the Sender could be invoking putUpdate() in a Receiver that was still alive, but the ObjectAdapter had been desroyed. A twoway ice_ping() created the exception.

    Regards --Roland
  • Originally posted by rhochmuth
    We use oneways for many of our invocations mainly for performance. We have a p2p application in that both ends are clients and servers. I'll call one end the Receiver and the other end the Sender which is the terminology we use.

    The Receiver invokes requestUpdate(). Then the Sender does a series of putUpdates() and finally an endUpdate(). Then the Receiver initiates another requestUpdate().The main point,here is that the Sender only does something in response to a Receiver request.

    OK, so the sender is the server in the initial phase, when it waits for a request from a receiver. Then, during the transfer phase, the sender is the client. The sender ends the transfer phase when it calls endUpdate(), at which point it assumes the server role again.
    So if the Receiver is killed I believe what we observed was a Sender waiting for a new request. We would never see the ConnectionLost exception since there never was another method invocation, such as putUpdate(), on the Sender side.

    Correct. Because the sender is the server initially, if the receiver dies, the server sees a disorderly connection closure. But it can't really throw an exception anywhere because the application does not hold the thread of control at that point. If you set the Ice.Warn.Connections property to 1, the server will report the connection loss to the logger though.
    I'm a little hazy on what happened to the socket exceptions in the Ice run time. I thought Ice caught them and did not propogate them up the call stack, but I might be mistaken. The other possiblity, is that they were propogated, but they weren't in a good location for us to use.

    The error handling differs for client and server. For clients, any socket errors that occur during call dispatch are caught by the run time. The run time then retries the request if that won't violate at-most-once semantics and if there is a chance that a retry might actually succeed. If the retry (or retries) fail, the error is propagated to the application in form of an exception.

    For servers, there isn't a lot that can be done to let the application know that something went wrong. For example, suppose the application is in the middle of the processing for an incoming operation invocation and then, while the operation is still executing, the connection is lost. When the operation completes and executes the final return statement at the end of the operation implementation, the thread of control returns to the server-side run time. The run time at this point tries to marshal the results back to the client but, of course, because the connection has dropped, cannot do so. At that point, there is no application thread of control that could be told about the error, so the best that the server side run time can do is to log that something didn't work.
    So that was the first reason for using and ice_ping(). Our Sender allocates a lot of memory per Receiver and we didn't want to keep this around when the Receiver was killed. A Ice invocation never occured on the Sender side in this case because it needed to be initiated by the Receiver.

    Right. The sender will find out that the receiver is no longer there only if it tries to invoke an operation on the receiver.
    The scrubber thread that performed ice_pings at 1-5 sec intervals that I mentioned earlier seemed like a good way to test whether the Receiver was alive.

    That's exactly the sort of thing ice_ping() is good for. It allows you to see whether the target object is still reachable without doing anything else.
    The second reason was that since we use oneways the ObejctNotFound exception was not thrown. So in this case the Sender could be invoking putUpdate() in a Receiver that was still alive, but the ObjectAdapter had been desroyed. A twoway ice_ping() created the exception.

    Right. The price of using oneways is that no errors are reported back to the sender. If you want to know if something went wrong, you must use a twoway invocation. Again, ice_ping() is just the thing for that.

    So, what you have done seems entirely reasonable. ice_ping() is used exactly what it is meant to be used for, and the Ice run time is behaving exactly as intended.

    Cheers,

    Michi.