Re: Transaction timeouts

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