Re: Transaction timeouts

Well OK it took a few minutes to  put this feature in so there it is. 
Now you can solicit for retransmission notifications on client 
transactions ( although the stack actually does the retransmission ).

Here it is :

SIPClientTransaction.setNotifyOnRetransmit ( boolean  )


Its pretty simple. You just get notificatoin of a retransmission from 
the client transaction but the retransmission is actually done by the 
stack.  I think it does what you want -- it will allow you to kill off 
the transaction early using transaction.terminate if you want. Its 
untested code - give it a try and tell me if it works. I'll try to get 
somethign like it into the next rev of the spec ( assuming that there is 
one ). I can see why it is needed.

Ranga

M. Rangnathan wrote:

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