Chronological Thread 

< Chronological >      < Thread >

---

Dear Sunil, dear all,

I think I understood the question in a different way, and that
was what I took from the perceived message flow Hideki described.

Am Dienstag, 9. April 2002 18:25 schrieb Ghelani Sunil-SGHELAN1:
> Andreas,
>
> I'm sorry but could you clarify what Hideki is doing wrong here. Is it not
> possible for 2 applications to open multiple associations between them so
> long as at least one application is using different port numbers ?
> App 1: port A, IP A <-----------> App 2: port B, IP B
> App 1: port C, IP A <-----------> App 2: port B, IP B

I think Hideki referred to the following (and please correct me
if I am wrong !):

Host 1 Host 2
App 1: port A IP A <-----------> App 2 - Process1: port C, IP B
Host 3 (or 1) /------> App 2 - Process2: port D, IP B
App 1: port B,IP C <----

Now, we have two distinct processes running on one host, which
by default means, that one packet arriving for one host will
always be OOTB for one of these processes.

> Isnt this what Hideki was trying to accomplish ? Why should SCTP consider
> the second INIT as an OOTB ?

The upper case you mentioned should work as long as only one
process is running that is linked to the sctplib.

That problem is inherent to the notion of having an SCTP
instance, when you are in userland, and can in fact have
more than one protocol instance.
Of course, you can only really avoid that when you are in
the kernel...

>
> -----Original Message-----
> From: Andreas Jungmaier
> [mailto:ajung AT exp-math.uni-essen.de]
> Sent: Tuesday, April 09, 2002 4:16 AM
> To:
> discussion AT sctp.de;
> Hideki Kishida
> Subject: Re: [SCTP-Discussion] not able to execute application
>
> > 2. I am not able to execute the plural application.
> > When it tries to establish the association with the 2nd
> > application abort is done.
>
> Yes, and that is okay like that. See RFC 2960, section 8.4.
> If you run 2 instances (i.e. 2 processes), one process is not able
> to know that the other runs (unless they have some IPC, which the
> do NOT have). To make things work in that case, you can set a
> library (i.e. global) flag, which will stop the sending of ABORT
> messages when a message is out of the blue.
> (use
> int sctp_setLibraryParameters(SCTP_LibraryParameters *params);
> int sctp_getLibraryParameters(SCTP_LibraryParameters *params);
> for that)
> Please note that this is a "work-around", which actually violates
> RFC 2960, but well :-)
>
> The other solution would be to make the two instances run
> in one process.

---

• [SCTP-Discussion] not able to execute application, Hideki Kishida, 04/09/2002
  • Re: [SCTP-Discussion] not able to execute application, Andreas Jungmaier, 04/09/2002
  • <Possible follow-up(s)>
  • Re: [SCTP-Discussion] not able to execute application, Andreas Jungmaier, 04/10/2002

---

Archive powered by MHonArc 2.6.19+.