Re: Transaction timeouts

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!