Re: Transaction timeouts

Will that work? You need multiple sockets unles all you ever do is talk 
to a single destination. The ICMP is delivered asynchronously and will 
not be cached unless the socket is bound. Thus when the ICMP comes back 
the binding better not have changed in the meanwhile. If it does the 
ICMP is dropped I believe and hence the solution will not work in 
general. This feature may be hard to support in general using ICMP and 
it is not guaranteed to work anyway.

 However this does point out the need for having a retransmission alert 
facility for the client transaction as well.  I think I'll add 
ClientTransaciton.solicitRetransmissionAlerts ( analog of what exists on 
the serverTransaction )  into the implementation  and for the next rev 
of the spec.  Andrew, do you want to file a feature request and I'll 
work on it when I can find the time ( or you can and submit a diff 
listing when you have it worked out ).

Regards,

Ranga

Jeroen van Bemmel wrote:

> perhaps you can try to call connect() on the single UDP socket each 
> time you send a datagram. Adds some overhead, but may provide feedback 
> when unreachable
>
> Suggest to try something like:
> if (options.checkUnreachable ) socket.connect( addr );
> socket.sendto( addr )
>
> Regards,
> Jeroen
>
> M. Rangnathan wrote:
>
>> Yes that is correct and that is a good observation. However, if we can
>> come up with a stack config parameter to support this behavior that
>> might be possible ( at the cost of scalability ). The default would
>> work the way it currently does (i.e. single socket).
>>
>> Ranga
>>
>> Jeroen van Bemmel wrote:
>>
>>> IIRC you can only learn about ICMP errors if you use a connected UDP
>>> socket (in Java at least). Unfortunately that means you would need to
>>> create a socket for each peer, which scales poorly.
>>>
>>> Regards,
>>> Jeroen
>>>
>>> M. Rangnathan wrote:
>>>
>>>> Andrew T Gin wrote:
>>>>
>>>>> Hi
>>>>>
>>>>>> You can be informed of retransmission alerts on the Server
>>>>>> transaction. See ServerTransaction.enableRetransmissionAlerts. On
>>>>>> the client side of the transaction, there is no retransmission
>>>>>> alert.
>>>>>
>>>>>
>>>>>
>>>>> I'm interested in the reasoning behind this :)
>>>>
>>>>
>>>>
>>>>
>>>> We did not think it was necessary. What is the use case? On the
>>>> server side, if you want to remain true to RFC 3216, the server
>>>> retransmits till ACK
>>>>
>>>>>>>     timeOutEvent) method only ever receives Timeout.TRANSACTION
>>>>>>>     timeout events. How do I make it so my application is
>>>>>>> notified of retransmit
>>>>>>>     timeouts? Are they received at processTimeout?
>>>>>>>
>>>>>>>     When the destination host is unreachable, the application
>>>>>>>     gets ICMP unreachable replies to each UDP retransmission. Is
>>>>>>> it possible to be
>>>>>>>     notified *immediately* when the destination is unreachable?
>>>>>>>
>>>>>> Let me think of this a bit. I could use the public void
>>>>>> processIOException(IOExceptionEvent exceptionEvent)   event
>>>>>> notification mechansm for this.  How does the UDP socket see
>>>>>> this. I think I would have to use  SOCTL to enable ICMP  packets
>>>>>> to be seen right ?. Is the feature available on J1.42 ? If not it
>>>>>> becomes a J 5 only thing which I want to avoid if possible. I
>>>>>> will take a look to see if I can hook this in but some hacking
>>>>>> from you would speed the process. See if you can hack
>>>>>> UDPMessageChannel to get notifications for ICMP packets. Call a
>>>>>> dummy method when you get the necessary notificaiton. I'll take
>>>>>> it from there.
>>>>>
>>>>>
>>>>>
>>>>> So it doesn't appear to be a current way to do it? I was more
>>>>> interested in whether this was possible with the current
>>>>> implementation. Ill just try work around it :D THanks for your
>>>>> efforts!
>>>>
>>>>
>>>>
>>>>
>>>> No there is not but there should be. Its an important feature that
>>>> is missing. Figure out how to read ICMP messages from the UDP socket
>>>> imbedded in UDPMessageChannel. If needed, we can make a 1.5 only
>>>> feature that allows you to inform the application asynchronously
>>>> when an ICMP notification comes along. If you find a work around ,
>>>> share it here and we can figure out how to make it work in the
>>>> stack.
>>>>
>>>>>
>>>>> Currently, TCP 'io exceptions' do not go through
>>>>> processIOException; they are caught as a SIP exception in the try
>>>>> catch block of each method. So if the UDP "io exception"
>>>>> implemented should they be treated the same?
>>>>
>>>>
>>>>
>>>>
>>>> Are you using JSIP 1.2 ? If so, IO Exceptions should be reported as
>>>> IOExceptions. If not there is a bug.
>>>>
>>>>
>>>>>> That would be in violation of the SIP transaction state machine -
>>>>>> something that I want to avoid. You can try implementing the
>>>>>> setBaseTimer on SipProvider ( currently disabled  -- throws
>>>>>> UnsupportedOperation).
>>>>>
>>>>>
>>>>>
>>>>> So this is a 'requirement' of SIP? I guess so from the RFC. Again
>>>>> I'll work around this. THanks again!
>>>>>
>>>>>>>
>>>>>>>     Thanks for your help, I'm usually a bit sceptical of mailing
>>>>>>> lists, as
>>>>>>>     questions usually go unanswered, so even if I happen to  find
>>>>>>> someone
>>>>>>>     else with the exact same problem, sometimes there are no
>>>>>>> replies!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Have faith. :-)
>>>>>
>>>>>
>>>>>
>>>>> What I meant here was that this Jain-SIP project is practically a
>>>>> model of how all projects should be! Active support, quick
>>>>> replies, a working implementation, and most importantly,
>>>>> comprehensive documentation!
>>>>
>>>>
>>>>
>>>>
>>>> Ah! I should put this up on the user experiences page. :-)
>>>>
>>>>>
>>>>> Thanks for all your help so far! I'll make sure to acknowledge you
>>>>> all in my thesis :)
>>>>
>>>>
>>>>
>>>>
>>>> Thanks. Keep hacking till you get there. :-)
>>>>
>>>> Ranga
>>>>
>>>>> Andrew 
>>>>
>
>


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!