Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixing a couple of bugs in sctp.c in burst transfers #2427

Merged
merged 1 commit into from
Nov 23, 2020

Conversation

afshin2003
Copy link
Contributor

In janus_sctp_pending_message_create the len attribute was not set properly.
In the burst transfers, packets got stuck in pending_messages queue!. To fix this the new function janus_sctp_data_ready is called in case of SCTP_SENDER_DRY_EVENT. I moved the first loop of janus_sctp_send_data function to the new created function to push pending messages to sctp stack. At the end of function I called the janus_dtls_sctp_data_ready function.

In janus_sctp_pending_message_create the len attribute was not set properly.
In the burst transfers, packets got stuck in pending_messages queue!. To fix this the new function janus_sctp_data_ready is called in case of SCTP_SENDER_DRY_EVENT. I moved the first loop of janus_sctp_send_data function to the new created function to push pending messages to sctp stack. At the end of function I called the janus_dtls_sctp_data_ready function.
@januscla
Copy link

januscla commented Nov 8, 2020

Thanks for your contribution, @afshin2003! Please make sure you sign our CLA, as it's a required step before we can merge this.

Copy link
Member

@lminiero lminiero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I added a comment inline.

m = g_queue_peek_head(sctp->pending_messages);
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure removing this is a good idea. The main reason why we tried to send all pending messages before sending the data we were just asked to send was to ensure the proper order of the messages. Since you removed this, and now pending messages are sent by the "dry" event, it means it's going to be very likely that a message sent now with janus_sctp_send_data will be sent before a pending message waiting to be sent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this can not happen.
janus_sctp_send_data will either enqueue the message (in case we are buffering in pending_message) or send it right away.
Once DRY_EVENT occurs, the pending_message will be traversed in FIFO order.

@atoppi
Copy link
Member

atoppi commented Nov 9, 2020

Thanks for the effort @afshin2003, I think this is a good enhancement over the current implementation.

What you are proposing is a way to avoid message dropping (aka flow control) in case of bursts and I see how you accomplish this by starting the en-queuing in janus_sctp_send_data in case of EAGAIN and continuing to en-queue if a queue is not empty.
Then the queue is emptied in FIFO order when DRY_EVENT is received from the stack.

However I have an observation.
Even being an improvement, there is still room for dropped messages. In case we buffer a huge amount of messages, once DRY_EVENT occurs, janus will try to send all the messages in the queue and any error like EAGAIN will lead to a drop. This is not a bug in the PR and this behavior comes from the existing implementation. Anyway I think it is worth noting since the PR claims to fix "dropped messages in case of bursts".

@uxmaster
Copy link
Contributor

uxmaster commented Nov 9, 2020

It seems the messages are left in the queue in the case of EAGAIN, so they're not dropped, or am I missing something?

@atoppi
Copy link
Member

atoppi commented Nov 9, 2020

@uxmaster you're right, we are just peeking the head with g_queue_peek_head.

@lminiero
Copy link
Member

Apologies for the very late reply: we've been busy with the IETF meeting and I've fallen a bit behind with reviews. I think the doubts I had are cleared, after the discussion I read above, so this is good to go for me. Thanks again, @afshin2003, merging! ✌️

@lminiero lminiero merged commit 741936c into meetecho:master Nov 23, 2020
@afshin2003
Copy link
Contributor Author

So sorry guys for very late response :(
I was so busy on my project and could not check here!
I'm really appreciated for the good job you have been doing on this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants