Suddenly, the unsent data size becomes zero. Why? #651
Comments
|
Is this the complete logging you get while this happens? The interesting part is that the I find it also strange that the |
|
The opening of the data channel is done by Chrome. I am running the following usrsctp system call. Also, I have enabled non-blocking and SCTP_NODELAY in socket options. |
|
Only the following logs are output. usrsctp/usrsctplib/netinet/sctp_output.c Lines 14815 to 14818 in b29c220 Only the log of the thread where the problem occurred is extracted. |
Does it mean that the sender is a program you have written and is using |
I would be interested in a complete log. If you don't want to post it here, you can send it to me privately: [email protected]. |
Yes. Get logs if possible. The memory usage of the process keeps increasing during the occurrence. |
|
@tuexen |
|
@tuexen The environment of my application is as follows. To me, it looks like 2 of the 7 streams stop receiving SACK. Sending thread - A: 729FF470 Sending thread - B: 729CD470 The logs are attached. |
|
Just to be clear: usrsctp is running on one machine, having 7 SCTP association talking to 7 endpoints in Chrome. When you write |
|
I guessed from the log. Thread 0x6F5BA470 is receiving SACKs until 10:57:26.908609. |
|
Some remarks: On the sending side we have: Now a SACK is processed, which acknowledges all outstanding data: That is why we start a retransmission timer on the next The next two The logging of the next In addition to that, there is a gap of 53 seconds. Investigating the gap, we see So line I agree, that things are strange. However, logging seems to stop for 53 seconds, and we have no idea what is happening during that time. When logging starts again, What to do next? I would suggest to compile You also might to apply which possibly gives an insight why no data is put on the wire after the time gap... Final note: the amount of data buffered in the stack during the time gap could come from the application continuing to call |
|
@tuexen I have enabled INVARIANTS, recompiled and changed the logs as advised. First, it occurs at 02:59:42. usrsctp_22030307_1.log A short time later, unsent is initialized. usrsctp_220307_2.log If this failure persists, the system will run out of memory. usrsctp_220307_1.log |
|
I just want to add that you can also get Chrome to log more - including a packet trace that can be converted to a PCAP file and opened in Wireshard: The file can be converted to a pcap (requires text2pcap that comes with Wireshark): Obviously, Chrome will run slower with these debug logs enabled... |
|
@tuexen 17:14:59.552463 has been successfully send From the next transmission,tf 0. |
|
@boivie |
I am using usrsctp as the SCTP stack for WebRTC.
In our environment, a strange phenomenon occurs.
That is, while continuing to deliver the video stream, the delivery suddenly stopped.
Wanting to figure them out, we enabled some of the logging in "sctp_lower_sosend()".
From around 23:03:14.069558
･"prw" has not changed.
･The value of unsent keeps increasing.
Also, at 23:04:34.589521, the value of unsent
I assume that the reason why the number of unsent data keeps increasing is that SACK is not returned from the destination.
Why is the value of unsent set to 0?
OS: Linux 32bit
SendBufferSize:1.5MB
Destination:Chrome browser,Edge
The text was updated successfully, but these errors were encountered: