onDisconnection not called when browser crashes

[natzcam]

onDisconnection is not called when browser crashes or browser process is stopped abruptly

[morskoyzmey]

maybe because client didn't send "bye-bye" to server, so server needs time to understand that client has gone.

[lechup]

For me it's naturall behaviour, check server's keepAlivePeer setting ... As @morskoyzmey wrote that is time You need to wait till client is treated as disconnected (in logs You can see the same message as on disconnection so I assume it should call onDisconnection event).

Note: Consider putting such things on mailing list not into issues ... issue is something that You know that You've found ;)

[cumulusdev]

Yes, I confirm. On browser crash, the server receives nothing... Then, the server will see the client death after a timeout of 140sec (which allows to support clients hardware reconnection!), and call the onDisconnection event before to delete the session. Beware, "keepAlivePeer" is something of completly different... It's a value to make working the "UDP hole punching" exploit (which allows P2P between browser), but without relation with that

[qiwsir]

" the server will see the client death after a timeout of 180sec". Can I change this time? and how? Thank you.

[morskoyzmey]

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

[cumulusdev]

Hi,

Yes, because RTMFP supports peer reconnection even if their network configuration change, this timeout is done to allow it, the value has been aligned with the official RTMFP value (by this way, the exact value is 140sec). I would keep it not configurable because a more lower time risks to encroach with other messages frequency like keepalive peer and server.

The solution proposes by morskoy sounds good, you can use the client event onManage (called every 2 sec) to check clients without activity since a long time.

Now to avoid to add a new "keepalive" packet, I have just added for your need a new "client.elapsedFromReception" property (time elapsed in milliseconds since the last packet received): https://github.com/OpenRTMFP/Cumulus/commit/177bc2fe8dd4b6542245f9a313777835276b3371

Like that you can check this value on client:onManage event (every 2 seconds) and disconnects the client if you consider that this time is too long for your usage (client.writer:close()).

2014-06-26 5:41 GMT+02:00 morskoyzmey notifications@github.com:

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47184857.

[qiwsir]

Hi,

Thank you very much.

I am a Chinese. I am studying Cumulus in my project. It is very good. And I am trying to translate its wiki into Chinese,too. Please read:https://github.com/qiwsir/Cumulus/wiki

When I finish it, I will publish it in a lonely webpage.

于 2014年06月26日 16:09, cumulusdev 写道:

Hi,

Yes, because RTMFP supports peer reconnection even if their network configuration change, this timeout is done to allow it, the value has been aligned with the official RTMFP value. I would keep it not configurable because a more lower time risks to encroach with other messages frequency like keepalive peer and server.

The solution proposes by morskoy sounds good, you can use the client event onManage (called every 2 sec) to check clients without activity since a long time.

Now to avoid to add a new "keepalive" packet, I have just added for your need a new "client.elapsedFromReception" property (time elapsed in milliseconds since the last packet received): https://github.com/OpenRTMFP/Cumulus/commit/177bc2fe8dd4b6542245f9a313777835276b3371

Like that you can check this value on client:onManage event (every 2 seconds) and disconnects the client if you consider that this time is too long for your usage (client.writer:close()).

2014-06-26 5:41 GMT+02:00 morskoyzmey notifications@github.com:

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47184857.

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47198591.

Qi Wei

Welcome you:www.itdiffer.com http://www.itdiffer.com

[cumulusdev]

Hi,

Oh interesting, thanks for your interest, Maybe you should keep an eye to Mona project: https://github.com/MonaSolutions/MonaServer It's not completly finished, but will make Cumulus obsolete (more light, more fast, and more complete). By this way, Mona is currently used in production for RTMFP protocol, and it looks stable.

Best, Mathieu

2014-06-30 11:44 GMT+02:00 老齐 notifications@github.com:

Hi,

Thank you very much.

I am a Chinese. I am studying Cumulus in my project. It is very good. And I am trying to translate its wiki into Chinese,too. Please read:https://github.com/qiwsir/Cumulus/wiki

When I finish it, I will publish it in a lonely webpage.

于 2014年06月26日 16:09, cumulusdev 写道:

Hi,

Yes, because RTMFP supports peer reconnection even if their network configuration change, this timeout is done to allow it, the value has been aligned with the official RTMFP value. I would keep it not configurable because a more lower time risks to encroach with other messages frequency like keepalive peer and server.

The solution proposes by morskoy sounds good, you can use the client event onManage (called every 2 sec) to check clients without activity since a long time.

Now to avoid to add a new "keepalive" packet, I have just added for your need a new "client.elapsedFromReception" property (time elapsed in milliseconds since the last packet received):

https://github.com/OpenRTMFP/Cumulus/commit/177bc2fe8dd4b6542245f9a313777835276b3371

Like that you can check this value on client:onManage event (every 2 seconds) and disconnects the client if you consider that this time is too long for your usage (client.writer:close()).

2014-06-26 5:41 GMT+02:00 morskoyzmey notifications@github.com:

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

— Reply to this email directly or view it on GitHub <https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47184857 .

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47198591.

Qi Wei

Welcome you:www.itdiffer.com http://www.itdiffer.com

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47513029.

[qiwsir]

Thank you.

I have forked it in Github.com. I will learn it hard.

于 2014年06月30日 21:00, cumulusdev 写道:

Hi,

Oh interesting, thanks for your interest, Maybe you should keep an eye to Mona project: https://github.com/MonaSolutions/MonaServer It's not completly finished, but will make Cumulus obsolete (more light, more fast, and more complete). By this way, Mona is currently used in production for RTMFP protocol, and it looks stable.

Best, Mathieu

2014-06-30 11:44 GMT+02:00 老齐 notifications@github.com:

Hi,

Thank you very much.

I am a Chinese. I am studying Cumulus in my project. It is very good. And I am trying to translate its wiki into Chinese,too. Please read:https://github.com/qiwsir/Cumulus/wiki

When I finish it, I will publish it in a lonely webpage.

于 2014年06月26日 16:09, cumulusdev 写道:

Hi,

Yes, because RTMFP supports peer reconnection even if their network configuration change, this timeout is done to allow it, the value has been aligned with the official RTMFP value. I would keep it not configurable because a more lower time risks to encroach with other messages frequency like keepalive peer and server.

The solution proposes by morskoy sounds good, you can use the client event onManage (called every 2 sec) to check clients without activity since a long time.

Now to avoid to add a new "keepalive" packet, I have just added for your need a new "client.elapsedFromReception" property (time elapsed in milliseconds since the last packet received):

https://github.com/OpenRTMFP/Cumulus/commit/177bc2fe8dd4b6542245f9a313777835276b3371

Like that you can check this value on client:onManage event (every 2 seconds) and disconnects the client if you consider that this time is too long for your usage (client.writer:close()).

2014-06-26 5:41 GMT+02:00 morskoyzmey notifications@github.com:

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

— Reply to this email directly or view it on GitHub

<https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47184857 .

— Reply to this email directly or view it on GitHub

https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47198591.

Qi Wei

Welcome you:www.itdiffer.com http://www.itdiffer.com

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47513029.

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47528139.

Qi Wei

Welcome you:www.itdiffer.com http://www.itdiffer.com

[qiwsir]

Hi

I asked you some questions before.

Now I am using Cumulus. It is very good.

I have saved a file that the audio stream, like :

function onAudioPacket(client,publication,time,packet) if audioFile then audioFile:write(packet); end end

'audioFile' is the variable of filename that stored the audio stream.

But How can I play these file? I read TODO in your github, you said:

Audio and Video Recording feature (even if it's already possible by a scripting way)

Can you tell me how to do ?

thank you very much.

QiWei

2014-06-30 21:37 GMT+08:00 qiwei qiwsir@gmail.com:

Thank you.

I have forked it in Github.com. I will learn it hard.

于 2014年06月30日 21:00, cumulusdev 写道:

Hi,

Oh interesting, thanks for your interest, Maybe you should keep an eye to Mona project: https://github.com/MonaSolutions/MonaServer It's not completly finished, but will make Cumulus obsolete (more light, more fast, and more complete). By this way, Mona is currently used in production for RTMFP protocol, and it looks stable.

Best, Mathieu

2014-06-30 11:44 GMT+02:00 老齐 notifications@github.com notifications@github.com:

Hi,

Thank you very much.

I am a Chinese. I am studying Cumulus in my project. It is very good. And I am trying to translate its wiki into Chinese,too. Please read:https://github.com/qiwsir/Cumulus/wiki

When I finish it, I will publish it in a lonely webpage.

于 2014年06月26日 16:09, cumulusdev 写道:

Hi,

Yes, because RTMFP supports peer reconnection even if their network configuration change, this timeout is done to allow it, the value has been aligned with the official RTMFP value. I would keep it not configurable because a more lower time risks to encroach with other messages frequency like keepalive peer and server.

The solution proposes by morskoy sounds good, you can use the client event onManage (called every 2 sec) to check clients without activity since a long time.

Now to avoid to add a new "keepalive" packet, I have just added for your need a new "client.elapsedFromReception" property (time elapsed in milliseconds since the last packet received):

https://github.com/OpenRTMFP/Cumulus/commit/177bc2fe8dd4b6542245f9a313777835276b3371

Like that you can check this value on client:onManage event (every 2 seconds) and disconnects the client if you consider that this time is too long for your usage (client.writer:close()).

2014-06-26 5:41 GMT+02:00 morskoyzmey notifications@github.com notifications@github.com:

You could send to "server" (other peers) custom "keepalive" messages at desired intervals. "Server" (other peers) should check time of last received message and consider about client probable disconnection.

— Reply to this email directly or view it on GitHub < https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47184857 .

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47198591 https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47198591.

Qi Wei

Welcome you:www.itdiffer.com http://www.itdiffer.com http://www.itdiffer.com

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47513029 https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47513029.

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-47528139.

Qi Wei

Welcome you:www.itdiffer.com

QiWei

[thomasjammet]

Hi QiWei,

In your function "onAudioPacket" you have the raw audio data. To record a valid file you need to add container information (for FLV : http://en.wikipedia.org/wiki/Flash_Video#Flash_Video_Structure).

There are other possibilities using MonaServer, please contact me (jammetthomas@gmail.com) if you need more support.

I advise you to use MonaServer which is now in a stable version.

[qiwsir]

I like to use MonaServer, Are there some documents about it?

[thomasjammet]

For those who wants to use MonaServer our documentation is here : http://monasolutions.github.io/MonaServer/

--

Thomas JAMMET Freelancer 2 Rue Mila - 82000 Montauban (France) Tel. : (+33) 06 23 46 39 80 http://fr.linkedin.com/pub/thomas-jammet/5a/411/60b/

2014-12-03 2:50 GMT+01:00 老齐 notifications@github.com:

I like to use MonaServer, Are there some documents about it?

— Reply to this email directly or view it on GitHub https://github.com/OpenRTMFP/Cumulus/issues/82#issuecomment-65339632.

[qiwsir]

Thank you . I have done it.