SCTP Discussions

Text archives Help


RE: [SCTP-Discussion] RE: discussion digest, Vol 1 #113 - 7 msgs


Chronological Thread 
  • From: Tuexen Michael <Michael.Tuexen AT icn.siemens.de>
  • To: "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: RE: [SCTP-Discussion] RE: discussion digest, Vol 1 #113 - 7 msgs
  • Date: Tue Jul 17 11:35:02 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

Dear Harish,

the change came in when we tested the RESTART case.
For the endpoint detecting the restart the restarted
assoc should be described with a unique ID the the
local tag changes. So we introduced a assoc ID which
is independend from the local tag.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From:
> hari AT cosystems.com
>
> [SMTP:hari AT cosystems.com]
> Sent: Tuesday, July 17, 2001 6:15 AM
> To:
> discussion AT sctp.de
> Subject: [SCTP-Discussion] RE: discussion digest, Vol 1 #113 - 7 msgs
>
> hello Michael, Andreas,
> Can i know the requirement of addition of "assocId" in the
> Associations
> Structure?. If i am not wrong
> in the earlier version the tagLocal is used to be associationID.
> -Rgds
> Harish K.
>
>
> -----Original Message-----
> From:
> discussion-admin AT sctp.de
>
> [mailto:discussion-admin AT sctp.de]On
> Behalf Of
> discussion-request AT sctp.de
> Sent: Sunday, July 15, 2001 3:31 PM
> To:
> discussion AT sctp.de
> Subject: discussion digest, Vol 1 #113 - 7 msgs
>
>
> Send discussion mailing list submissions to
>
> discussion AT sctp.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.sctp.de/mailman/listinfo/discussion
> or, via email, send a message with subject or body 'help' to
>
> discussion-request AT sctp.de
>
> You can reach the person managing the list at
>
> discussion-admin AT sctp.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of discussion digest..."
>
>
> Today's Topics:
>
> 1. Unclear statement (Marjan Bozinovski)
> 2. Re(2): [SCTP-Discussion] Path failure management
> (=?ISO-8859-1?Q?Michael=20T=FCxen?=)
> 3. Re: Unclear statement (=?ISO-8859-1?Q?Michael=20T=FCxen?=)
> 4. Re: Unclear statement (Marjan Bozinovski)
> 5. Re(2): [SCTP-Discussion] Unclear statement
> (=?ISO-8859-1?Q?Michael=20T=FCxen?=)
> 6. sctp protocol numbers (Mark Oldham)
> 7. Re: sctp protocol numbers (=?ISO-8859-1?Q?Michael=20T=FCxen?=)
>
> --__--__--
>
> Message: 1
> From: "Marjan Bozinovski"
> <marjanb AT cpk.auc.dk>
> To:
> <discussion AT sctp.de>
> Date: Sat, 14 Jul 2001 16:05:09 -0700
> charset="iso-8859-1"
> Subject: [SCTP-Discussion] Unclear statement
> Reply-To:
> discussion AT sctp.de
>
> Dear Michael, dear Andreas,
>
> Please explain me the following statement that I have found in the SCTP
> documentation:
>
> "So far, there has been only one ULP instance. In the future, the
> communication between SCTP and the ULP shall be done with a locally bound
> UDP socket that will be used to register a ULP instance with the SCTP
> instance. Thus it will be possible to asynchronously call functions of the
> SCTP protocol engine from a process that sends data on a local UDP socket,
> and is passed the results and other notification messages back over that
> socket."
>
> Best regards,
> Marjan
>
>
> --__--__--
>
> Message: 2
> From: =?ISO-8859-1?Q?Michael=20T=FCxen?=
> <Michael.Tuexen AT micmac.franken.de>
> To:
> <discussion AT sctp.de>
> Subject: Re(2): [SCTP-Discussion] Path failure management
> Date: Sat, 14 Jul 2001 16:12:34 +0200
> Reply-To:
> discussion AT sctp.de
>
> Dear Marjan,
>
> well, it does not make much sense for the terminal app to send data
> on multiple streams, but for testing ...
>
> So first of all I should say that the implementation does support
> bundling only in a limited way. If you really want to implement it,
> you need a timer which is started when a sctp=5Fsend is called and the
> timer is not running yet. The user data is stored and not send.
> If sctp=5Fsend is called when the timer is running, the user data is
> also send. When the timer runs off, you really send the user data,
> which means multiple DATA chunks bundled into one SCTP packet. This
> bundling precedure is NOT implemented yet.
>
> When does the implementation bundle=3F>
>
> - In case of retransmission multiple DATA chunks are bundled as describe=
> d
> in RFC 2960.
> - If you call multiple times sctp=5Fsend within an callback function, fo=
> r
> example
> the data=5Farrive=5Fnotification.
> - In case of transmission, when it was not allowed to send out a SCTP pa=
> cket
> at the time sctp=5Fsend was called. So the userdata was stored and is =
> send out
> bundled later.
>
> So if you want to have multiple DATA chunks belonging to different strea=
> ms you
> could modify the echo=5Fserver or echo=5Ftool to send out DATA chunks on=
> all
> streams
> when a DATA chunk is received. If you do this in the data=5Farrive=5Fnot=
> ification
> you should see the behaviour you want to see. But I have to tested this
> yet, but
> I think it is a good idea and I will do this next week.
>
> Best regards
> Michael
>
> --
> e-mail:
> Michael.Tuexen AT micmac.franken.de
>
> On Sat, Jul 14, 2001, Marjan Bozinovski
> <marjanb AT cpk.auc.dk>
> wrote:
>
> >Dear Michael,
> >
> >Thank you for your response. I have forgotten the rules you described b=
> elow.
> >
> >My next question is related to the multi-streaming feature. The origina=
> l
> >terminal application sends data using only one stream. I have changed t=
> he
> >terminal application in such a manner that each time it sends a new dat=
> a, it
> >changes the stream IDs, incrementing it by 1. But, this does not essent=
> ially
> >changes the behaviour, because I still have one stream per transmitted
> >chunk.
> >So, the question is, how to modify the terminal application, so that, e=
> very
> >time it sends data, it can create several chunks, allocate to them diff=
> erent
> >stream IDs and bundle them in one SCTP packet, thus achieving to have
> >several, simultaneously used, parallel streams=3F
> >
> >Best regards,
> >Marjan
> >
> >
> >----- Original Message -----
> >From: "Michael T=FCxen"
> ><Michael.Tuexen AT micmac.franken.de>
> >To:
> ><discussion AT sctp.de>
> >Sent: Friday, July 13, 2001 1:54 PM
> >Subject: Re: [SCTP-Discussion] Path failure management
> >
> >
> >> Dear Marjan,
> >> see my comments below.
> >> Best regards
> >> Michael
> >>
> >> --
> >> e-mail:
> >> Michael.Tuexen AT micmac.franken.de
> >>
> >> On Fri, Jul 13, 2001, Marjan Bozinovski
> >> <marjanb AT cpk.auc.dk>
> >> wrote:
> >>
> >> >Hi,
> >> >
> >> >I have used SCTP pre-release 12 (including the patch issued by Andre=
> as
> >> >Jungmaier, in his reply on "Network status change in Pre 12", sent o=
> n the
> >> >21st June) and deployed the following scenario:
> >> >A dual-path communication between "terminal" and "echo=5Fserver", wh=
> ile
> >> >simulating a network failure.
> >> >The both sides were dual-homed and were connected via two LANs. Afte=
> r the
> >> >association was established, the path 0 was declared as primary path=
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion




Archive powered by MHonArc 2.6.19+.

Top of page