Summary
I found it is difficult to use pion/sctp alone because sctp.Association.Client and sctp.Association.Server take a "connected" UDP. These are equivalent to a child (server) socket and a client socket of TCP. What's missing in pion/sctp s "listening socket".
In the context of WebRTC, we use Client-Client simultaneous open, which is not practical in the cases of non-WebRTC (no-ICE, etc). Client-Server is possible, but it would be difficult to establish connection if there's a NAT in between.
Motivation
Introduce the usability of pion/sctp standalone in TCP style.
Describe alternatives you've considered
I have written a tool that enables TCP like listening socket capability. However, it cannot take advantage of "cookie-echo" (resembles to TCP-Syn-cookie) SCTP offers, which is a measure against DDoS attack (like spoofed SYN-flood in TCP) because internal chunk parsers are not exposed via its API.
We can use go-rudp as a reference.
Summary
I found it is difficult to use pion/sctp alone because sctp.Association.Client and sctp.Association.Server take a "connected" UDP. These are equivalent to a child (server) socket and a client socket of TCP. What's missing in pion/sctp s "listening socket".
In the context of WebRTC, we use Client-Client simultaneous open, which is not practical in the cases of non-WebRTC (no-ICE, etc). Client-Server is possible, but it would be difficult to establish connection if there's a NAT in between.
Motivation
Introduce the usability of pion/sctp standalone in TCP style.
Describe alternatives you've considered
I have written a tool that enables TCP like listening socket capability. However, it cannot take advantage of "cookie-echo" (resembles to TCP-Syn-cookie) SCTP offers, which is a measure against DDoS attack (like spoofed SYN-flood in TCP) because internal chunk parsers are not exposed via its API.
We can use go-rudp as a reference.