Question regarding reliability when using tcp exclusively for client-server communication and server-peer relaying. about coturn HOT 7 CLOSED

AFAIK, to be on the safe side please implement application level reliability.
(If you use WebRTC stack, in WebRTC in data transfer the sctp solves this for you.)

from coturn.

It is reliable if the server is not overloaded. Otherwise, it will start dropping messages.

Sent from my iPhone

On Aug 25, 2016, at 5:36 AM, misi [email protected] wrote:

AFAIK, to be on the safe side please implement application level reliability.
(If you use WebRTC stack, in WebRTC in data transfer the sctp solves this for you.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from coturn.

@mom040267 Does the client/peer get notified if their message is dropped?

from coturn.

No. How they can be notified ? There is no such a provision in Turn protocol.

Sent from my iPhone

On Aug 25, 2016, at 9:03 AM, Binshuo Hu [email protected] wrote:

@mom040267 Does the client/peer get notified if their message is dropped?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

from coturn.

@mom040267 From my understanding of RFC 6062, if the receiving side of the client/peer pair is slow, the TURN server should properly back pressure the sender if the pre-configured buffer is full rather than drop the message

section 5.4

Otherwise, the client connection is now called a client data
connection. Data received on it MUST be sent as-is to the associated
peer data connection.

from coturn.

On Thu, Aug 25, 2016 at 9:10 AM, Binshuo Hu [email protected]
wrote:

@mom040267 https://github.com/mom040267 From my understanding of RFC
6062, if the receiving side of the client/peer pair is slow, the TURN
server should properly back pressure the sender if the pre-configured
buffer is full rather than drop the message

This is what we are trying to do, actually.

But there is no such explicit requirement in the text. The section 5.4
could be understood differently.

Realistically, it is not very possibly on a multi-user server.

Oleg

section 5.4

Otherwise, the client connection is now called a client data
connection. Data received on it MUST be sent as-is to the associated
peer data connection.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#58 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFq2UELmAhDokm6xvy5mLghozGeXhIigks5qjb59gaJpZM4JswO2
.

from coturn.

I see, thanks for the explanation.

from coturn.