it's not Java-specific really.
Imagine you have an open TCP connection that has no traffic, and
somewhere inbetween there's a network failure. You will only know
about it when you start sending the data, and the TCP timeout occurs.
You will get the socket error exception only after all retransmission
attempts failed, and that may take quite some significant time. If
ICMP is allowed in the network, some failures would generate ICMP
messages which will speed up the process, but you can't rely on this.
So, if you need to know about the failure quickly enough, you need to
monitor the server reachability with some connectionless protocol,
like ICMP echo or some UDP-based keepalive.
On Wed, Aug 5, 2015 at 11:14 AM, Michael Jerris <mike@jerris.com> wrote:
> are you saying Java provides no way to detect a tcp socket disconnect?
>
>
> On Wednesday, August 5, 2015, Babak Yakhchali <babak.freeswitch@gmail.com>
> wrote:
>>
>> but if for example network connection is lost the socket will remain open
>> forever!
>>
>> On Wed, Aug 5, 2015 at 12:04 PM, Michael Jerris <mike@jerris.com> wrote:
>>>
>>> I would just detect the socket closing instead of using a heartbeat for
>>> sure
>>>
>>>
>>> On Wednesday, August 5, 2015, Babak Yakhchali
>>> <babak.freeswitch@gmail.com> wrote:
>>>>
>>>> Hi
>>>> I'm using pure java sockets (not current available esl implementations)
>>>> with event_socket to control sessions. to detect lan disconnects I'm using
>>>> session_heartbeat events every 1 second (this is adjustable). Considering
>>>> performance is this a bad approach or not ? any better suggestions?
>>>> if I execute enable_heartbeat before answering the call this message is
>>>> printed on console:
>>>> switch_core_session.c:1555 sofia/internal/1000@172.16.90.1 using
>>>> scheduler due to bypass media or media is not established.
>>>>
>>>> should I answer the session before calling enable_heartbeat?
>>>> thanks
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting@freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users@lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting@freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org