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. > >>> 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 <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"