On Thu, May 01, 2014 at 11:06:09PM +0200, Michael Tuexen wrote: > On 01 May 2014, at 22:42, Bernd Walter <ti...@cicely7.cicely.de> wrote: > > > On Thu, May 01, 2014 at 08:07:19PM +0200, Michael Tuexen wrote: > >> On 01 May 2014, at 14:49, Bernd Walter <ti...@cicely7.cicely.de> wrote: > >> > >>> I have an SOCK_SEQPACKET socket and want to setup an association > >>> without sending a message. > >> Just call connect() or sctp_connectx(). > > > > Cool - I wasn't sure about using *connect*() because tutorials only > > mention it for 1to1 sockets. > You might want to take a look at > http://tools.ietf.org/html/rfc6458#section-3.1.6 > http://tools.ietf.org/html/rfc6458#section-9.9 > sctp_connectx() also provides you a way to get the association id, > which is needed for 1-to-many style sockets.
Ah - there it is. So many sources to get things running, SCTP still is too new to easily find good sample code beyound basics. About the association id - so far I'm always using socket_addr. I may be able to track association IDs, but are they really unique? E.g. association shuts down and a new one gets the ID? I also use it to get the RTT, which is untested code so far. > >>> The background is that I want to keep the round-trip times of peer > >>> servers. > >>> I've enabled regular heartbeat and can use SCTP_GET_PEER_ADDR_INFO > >>> to get the RTT. > >>> But in case a host is down or services are restarted I don't have > >>> an association to ask, so I will need some way to (re)establish > >>> associations. > >>> This is done in a different thread as the normal socket operation, > >>> which uses EOR to write. > >>> If I send a (dummy)message to the socket I would have to add a mutex > >>> to not disturb the sending thread. > >> Does the above solve your issue? > > > > Yes. > > > > But I have another question. > > Which resources will connecting an unreachable peer use on my one to > > many socket? > Basically the resources for an association and it will run a timer for > retransmitting the INITs. Great - that's what I was hoping for. I may have enough troubles already with data for down hosts stuck in socket buffer, but this is a one time thing until the data times out. Thank you -- B.Walter <be...@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
