Subject: One connect() call to multiple servers?

From: Craig Rodrigues <[email-masked]>
Date: Tue, 24 Feb 2004 14:33:03 -0500

Hi,

I am looking at a few SCTP implementations: OpenSS7 SCTP,
LKSCTP, and the BSD SCTP implementation.

I want to conduct an experiment which exercises some
of the fault-tolerant/multihoming capabilities of SCTP.

Let's say I have this configuration:

                                 _____                              
      _____ -------------------->| B |  
      | A |                      -----
      _____                      192.168.0.2 
      192.168.0.1
          |                      _____
          |--------------------->| C |
                                 -----
                                 192.168.0.3

A is a client, and B and C are servers.

In B, I want to run a server program and do accept(192.168.0.2, port 10000).
In C, I want to run an identical server program and do 
accept(192.168.0.3, port 10000).

In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000).

(Note, I know I am omitting bind() and sctp_bindx() calls, but
 I just want to get my point across conceptually.) 

I want to then transmit data between
A and B via SCTP.  At some point, I want to cut the connection
between A and B, and then have the connection automatically
switch over to sending data between A and C. 

I would like to minimize the data loss during this switchover
time.

Can I run this sort of experiment with OpenSS7 SCTP, LKSCTP,
and BSD SCTP?  I have seen experiments run where
a server binds to multiple addresses on one host,
but I have never seen an experiment where a client binds
to multiple server addresses on different hosts.

Thanks.

-- 
Craig Rodrigues        Distributed Systems and Logistics, Office 6/325A
[email-masked]       BBN Technologies
(617) 873-4725         Cambridge, MA

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Feb 2004 21:10:32 +0100

Hi,

see my comments below.

Best regards
Michael

>       _____ -------------------->| B |
So, what you need are two associations. I"m assuming that you use
the one-to-one style socketapi. This means that you need two
sockets at A.
> In A, I want to connect(192.168.0.2:1000, 192.168.0.3:1000).
This does NOT work. connect accepts only one address, connect_x
accepts multiple, but they must be on ONE host.
So you need two connect calls using the two sockets.
> switch over to sending data between A and C.
This is host fail-over. This is not done by SCTP. An implementation
of RSerPool does this sort of failover.
> I would like to minimize the data loss during this switchover
Yes.
> to multiple server addresses on different hosts.
You need a session layer on op of it, see for example RSerPool.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 24 Feb 2004 14:11:42 -0700

Craig,

Generally SCTP only provides interface or path redundancy with
multihoming.  Adaptation layers provide mechanisms for host
redundancy.  For signalling protocols these are the SIGTRAN
User Adaptation layers, however, for a more general approach,
there is RSERPOOL that largely extends the concepts of SIGTRAN
into a general purpose framework for redundant server pooling.

Check out the rserpool WG archives at ietf.org.  The minutes
from IETF #58 provide a good status catchup if you have not
been following RSERPOOL.  There were volunteers to specify a
sort of "redundant socket layer" interface to RSERPOOL that
would accomplish what you are trying to do but also offer name
service, services directory, etc.

Unfortunately it appears that, like many SIGTRAN drafts, many
RSERPOOL drafts were stalled for over a year due to IETF
security policy.

Michael Tuxen had an early implementation of RSERPOOL running
over sctplib SCTP (check with Michael or www.sctp.de).  I
don't really know how far along it is or whether it can be
adapted to work with other SCTP implementations as well.

Perhaps others on this list can comment on availability of
RSERPOOL implementations.

That probably doesn't help you out too much right now, but the
RSERPOOL work is certainly worth following (and particularly
the "reliable socket layer" effort).

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Craig Rodrigues <[email-masked]>
Date: Tue, 24 Feb 2004 16:12:27 -0500

> So you need two connect calls using the two sockets.

Well, this connect() call actually does work if you use
OpenSS7 SCTP, since OpenSS7 SCTP allows you to pass in
an array of addresses.  However, this does not
conform to the SCTP socket API in the IETF drafts
(which LKSCTP implements).

> of RSerPool does this sort of failover.

If I don't want to use RSerPool, can I run a similar
experiment, where B and C are two separate server programs located
on the same host, but bound to two different network
interfaces (but same port)?

By the way, for the Rserpool code available at
http://www.sctp.de/rserpool.html, what SCTP implementation
does it work with?  It doesn't seem to compile with LKSCTP.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Feb 2004 22:43:34 +0100

Craig,

see my comments below.

Best regards
Michael

> (which LKSCTP implements).
You have to contact Brian...
> interfaces (but same port)?
No. SCTP provides path fail-over within one association. You are
talking about two separate processes which would have two
separate associations. Except, if you have one, set up the assoc
and then fork() into another process. But this is not that easy.
I assume that you are looking for a concept being able to handle
the failure of an SCTP endpoint. RSerPool is a solution for that.

> does it work with?  It doesn't seem to compile with LKSCTP.
Well, the released version works with the socketapilib.
The socketapi was changed in the meantime.
We have not released a new version for a long time, but we
do have a version which runs natively on the KAME stack
and the Linux stack. We will publish this version within the
next weeks. I can announce it also on the SCTP Impl list...

Best regards
Michael