Rework highlevel api

[iqualfragile]

So in sctp you have a Socket which is your applications point of presence, where it can receive or send messages. A Socket has 0-n Associations, which are connections between your socket and another socket on (most likely) another system. An Association then hosts up to u16 Streams. Streams are unidirectional data channels where you put data in on one side and it arrives on the other side. You can choose what guarantees you want to have, disabling/limiting reliable delivery and ordering per stream is a possibility. Incomming and Outgoing streams with the same Id are fully independent and do not need to be thought of as read/write-channel of the same "socket". This is currently not well-mapped.

• SctpStream is actually an Associaton.
• There is no way to sctp_peeloff an Association out of an SctpEndpoint into its own 1-1 Socket.
• the legacy tcp-style api is mixed with the SEQPACK/SCTP-API

I therefore propose to rework the api.

• do rename SctpStream into SctpAssociation or just Association, as its allready qualfied by stcp::Association
• allow peeling off an Association from an SctpEndpoint
• rename SctpEndpoint to SctpSocket or just Socket
• maybe Put the tcp-style api (mainly SctpListener) into sctp::tcp::SctpListener

[phsym]

Hi, Your suggestions seems legit. I'll get a look into it later since I have a few time currently to work on it (this is a pet project made for another pet project :smile: ) Feel free to contribute if you want to :wink:

A quick feedback to your propositions:

• The SctpStream name was more a reference to TcpStream, more than to the sctp streams. I'm ok to rename it to SctpAssociation
• Allow peeling off => OK
• Rename SctpEndpoint to SctpSocket => Not sure about this one, since this is not just a socket. (Have a look to the internal sctpsock::SctpSocket for what I call "just a socket"). But if you see real value to rename it, so OK.
• Move SctpListener to tcp package => Again, not sure about it.