Date: Thu, 1 May 2014 23:06:09 +0200 From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de> To: ticso@cicely.de Cc: freebsd-net@freebsd.org, Bernd Walter <ticso@cicely7.cicely.de> Subject: Re: How to create an SCTP association Message-ID: <F6DEDA81-9B8A-4FC7-9A18-8AA19A7748A1@lurchi.franken.de> In-Reply-To: <20140501204249.GB52252@cicely7.cicely.de> References: <20140501124908.GA50185@cicely7.cicely.de> <ABDB118B-FCB7-453C-B7FF-CDE7AF303333@lurchi.franken.de> <20140501204249.GB52252@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01 May 2014, at 22:42, Bernd Walter <ticso@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 <ticso@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. > >>> 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. > > My use case is a distributed hash table with many servers. > Clients connect to servers via local proxy and the local proxy tries to > stay in contact with all storage nodes - basicly to keep RTT values up > to date. > I initially plan 100 nodes per cluster, 2 cluster per location and > 2 location. > So such a proxy has to stay in touch with 400 peers of which 200 are > on a remote location. > Of course the remote location is rarely used, but in case of network > failure 200 peers are unreachable. > With TCP sockets the sockets are unrelated of each other. > In this case I may try to sctp_connect 200 offline peers and still > want to be able to reach the 200 local peers without additional latency. > Is there anything special to care about to not block the traffic > to the remaining peers in case a whole bunch of the others is offline? > Raising socket buffer on the proxy servers is not a problem, since > those have beafy RAM - the nodes however are tiny quad core ARM-A9 with > 2G RAM only, which they mostly need to keep hashtable indexes. I don't see a problem right now. I suggest to do some testing. In case of problems, please let me know. Best regards Michael > > -- > B.Walter <bernd@bwct.de> http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6DEDA81-9B8A-4FC7-9A18-8AA19A7748A1>