Question regarding reliability when using tcp exclusively for client-server communication and server-peer relaying.

[binshuohu]

I am currently trying to implement a peer-to-peer file transfer application, which is quite different for the common use of TURN for real-time communication that is not so sensitive about data loss.

So I'm wondering if I use tcp for client to TURN server communication and server-peer relaying, do I have the reliability as if the client connects to peer directly over tcp? Or do I still have to implement reliability at application level?

[misi]

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.)

[mom040267]

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 notifications@github.com 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.

[binshuohu]

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

[mom040267]

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 notifications@github.com 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.

[binshuohu]

@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.

[mom040267]

On Thu, Aug 25, 2016 at 9:10 AM, Binshuo Hu notifications@github.com
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
.

[binshuohu]

I see, thanks for the explanation.