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