[jitsi-dev] [jitsi-videobridge] Uses a PacketQueue for packets coming out of the SCTP stack in order to (#183)


#1

ensure that the calling thread does not block. We have
observed that blocking this thread (e.g. by having it eventually try
to write to a Socket) results in calls to usrsctp_socket to block (i.e.
to our inability to initialize any new SCTP sockets).
You can view, comment on, or merge this pull request online at:

  https://github.com/jitsi/jitsi-videobridge/pull/183

-- Commit Summary --

  * Uses a PacketQueue for packets coming out of the SCTP stack in order to

-- File Changes --

    M src/main/java/org/jitsi/videobridge/SctpConnection.java (54)
    M src/main/java/org/jitsi/videobridge/VideoChannel.java (2)

-- Patch Links --

https://github.com/jitsi/jitsi-videobridge/pull/183.patch
https://github.com/jitsi/jitsi-videobridge/pull/183.diff

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183


#2

could this potentially result in long datachannel connection times (~30 seconds)? we've seen that happen on occasion...not sure if that's just the nature of sctp or if it may be related to something like this.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183#issuecomment-200489666


#3

Possibly, but I think you would have noticed other problems and not just slow SCTP establishment. In what we observed, while the thread was blocked health checks never returned, at least some COLIBRI requests never returned and the statistics were broken.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183#issuecomment-200519119


#4

+ * The instance which we use to handle packets read from
+ * {@link #packetQueue}.
+ */
+ private final PacketQueue.PacketHandler<RawPacket> handler
+ = new PacketQueue.PacketHandler<RawPacket>()
+ {
+ @Override
+ public boolean handlePacket(RawPacket pkt)
+ {
+ if (pkt == null)
+ return true;
+
+ if (transformer == null)
+ return false;
+
+ System.err.println("XXX sending sctp data over DTLS");

System.err.println ? Forgot to remove before commit ?

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183/files/2950686de9274aaeaf27434ec51d59e890a4910b#r57334919


#5

+ * the SCTP stack which are to be sent via {@link #transformer}.
+ */
+ private final RawPacketQueue packetQueue;
+
+ /**
+ * The {@link DtlsPacketTransformer} instance which we use to transport
+ * SCTP packets.
+ */
+ private DtlsPacketTransformer transformer = null;
+
+ /**
+ * The instance which we use to handle packets read from
+ * {@link #packetQueue}.
+ */
+ private final PacketQueue.PacketHandler<RawPacket> handler
+ = new PacketQueue.PacketHandler<RawPacket>()

Don't really like creating anonymous class here, but that's just my opinion. Would prefer to have named class at the bottom, does the same thing.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183/files/2950686de9274aaeaf27434ec51d59e890a4910b#r57335248


#6

Merged #183.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/183#event-602060823