Obtain the verification tag through the interface.

[changdingfang]

Why is there no interface to obtain the verification tag through struct socket or assoc id?
I have multiple UDP sockets at the business layer that need to be associated with assoc id or struct socket. When the data is passed to the business layer in the receive_cb callback, I need to know which UDP socket this data should be sent through.

[tuexen]

The verification tag is not exposed to the upper layer, because it has only a meaning at the SCTP layer. There are even no guarantees related to uniqueness. For an SCTP endpoint operating in the 1-to-many style mode, you have the association identifier.

[changdingfang]

However, the association ID can only be obtained after a successful handshake. During the handshake process, how do I know which UDP socket the INIT-ACK should be sent to? I have multiple UDP sockets, and at this point, they are not yet associated.

[changdingfang]

The label in the diagram is incorrect; it should be writeCallback instead of receive_cb.

[tuexen]

Couldn't you use AF_CONN for what you want? See programs/ekr_loop_upcall.c? That should allow you to use the address of your UDP sockets as an address.

[changdingfang]

I reviewed that code, and I want to check if my understanding is correct. Every time a new connection comes in (I check myself for INIT data), it is associated through the following steps:

1. usrsctp_register_address registers the UDP socket.
2. usrsctp_socket creates a new struct socket.
3. usrsctp_bind.
4. usrsctp_set_upcall registers the callback for receiving packets on the new connection.

[tuexen]

This assumes that you use a single UDP socket for each SCTP association. Is that your model? Why do you need different UDP sockets?

[changdingfang]

Multiple UDP sockets are a business necessity.

[changdingfang]

After trying the above solution, it seems not feasible.

[changdingfang]

Creating multiple struct sockets and following the aforementioned process results in the inability to establish a connection on the client side.

[tuexen]

Are you implementing the client or server side?

[changdingfang]

server side

[tuexen]

OK. On the client side you could have used sctp_connectx() to get the association id. I guess I need to understand, why you want to have multiple UDP sockets. There are currently two supported modes:

1. Use SCTP/UDP/IPv[46] to allow NAT traversal. You can do this using a single UDP socket. SCTP performs the demultiplexing of SCTP associations.
2. Use of SCTP/DTLS. Here you have a single DTLS connection. It is not important that it is DTLS, but it is assumed to have a single connection. This is managed with a faked address.

Can you explain what the constraints for your use case with respect to the use of UDP sockets are?

[changdingfang]

I am working on the server side, and the current service architecture is that each client corresponds to a UDP socket. This means that if there are 100 client connections, the server side will have 100 UDP sockets.
Actually, when I use usrsctp, I can only pass a identifier associated with the UDP socket to usrsctp, and I cannot directly obtain the UDP socket.
Currently, I am using the WriteCallback registered by usrsctp_init to send SCTP data, but I do not have the association between usrsctp and the UDP identifier. I am unsure how to determine which UDP socket the WriteCallback sends data to during the handshake phase and subsequent data exchange phases.

[tuexen]

OK. What is the context? WebRTC? SCTP for signaling? Something else? I want to figure out if you have some other connection state (like a DTLS connection for WebRTC)...

[changdingfang]

Transmit custom business data and WebRTC communication. Between the UDP socket and SCTP, there is a layer of DTLS. It is precisely because of this that I cannot directly access the UDP socket, but can only obtain the associated identifier.