On 02 May 2014, at 00:04, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> 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? http://tools.ietf.org/html/rfc6458 guarantees them to be unique between all existing associations on a given socket. So two associations on different sockets can have the same id. The spec also allows them to be reused, as indicated at the end of: http://tools.ietf.org/html/rfc6458#section-8.1.8 In FreeBSD the assoc ID is a 32-bit counter which gets incremented and wrapped around. So it is reused after a long time... > 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. If you enable the SCTP_SEND_FAILED_EVENT you can get that data back if you want... Best regards Michael > > 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"
