Chronological Thread 

< Chronological >      < Thread >

---

Dear all,
see my comments below.
During the coding of an echo server I found some problems with
sctp.h. After discussing this with Andreas we will publish
an updated version.
Best regards
Michael

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

> -----Original Message-----
> From: Schruefer Wolfgang
> [SMTP:Wolfgang.Schruefer AT icn.siemens.de]
> Sent: Monday, February 26, 2001 3:02 PM
> To:
> 'discussion AT sctp.de'
> Subject: 2nd try: AW: [SCTP-Discussion] Request for comments: API for
> SCTP 1.0
>
> Dear Michael, Dear Andreas,
>
> thanks for this new API and its documentation. You spent a lot of effort
> and I like the result very much.
>
> Especially I like the new features :
> - all RFC-proposed functions are included
> - in sctp.h is no include of external header-files (socket.h / in.h /
> glib.h)
> - the IP-addresses are passed by string
> - the new paramenter "pointer to ULP data"
> - the many instance and association parameters
> - the documentation
> - ...
>
> Of course with this big stroke there are some (small) comments /questions:
>
> 1) InstanceParams:
> 1a) What is difference between my_rwnd and max_recvQueue?
> My idea about it:
> My_rwnd (number of bytes) is responsible for the calculation of a_rwnd
> passed back to the sender.
> Max_recvQueue is the number of chunks (not bytes!) in the recvQueue. If the
> limit is reached a_rwnd will be set to 0?
> Is this the idea?
[Tuexen Michael] My_rwnd is needed for the setup of the association.
Max_recvQueue
came up in a discussion with Wolfgang, so I really do not know the
semantics. Wolfgang,
could you clarify? Was is not a limit of the recvQueue?
>
> 1b) delay: I'd prefer it as an AssocParam
[Tuexen Michael] Yes!
> 1c) assoc/pathMaxRetransmits can be set also as AssocParam, do you really
> want it twice (but why not ...)?
[Tuexen Michael] Hmm, let us think about it.
> 2) AssocParams
> The parameters "valid CookeiLife" and "maxInitRetransmits" are defined by
> InstanceParams and make no sense here, because the values are not needed
> after COMMUNICATION_UP, or am I wrong?
[Tuexen Michael] Seems to be right!
> Please can you provide an explaination of the flowcontrol-values?
[Tuexen Michael] I think they are there to be able to supervise
them. Is it right, Andreas?
> 3) All Params
> If the ULP wants to change only one param, he needs to fill in all values.
> What do you think of this idea:
> You choose "int" instead of "unsigned int" for all of them. And then a
> negativ value means: "don't touch" ?
[Tuexen Michael] We thought about the following way: You will always
have a get_*
and a set_* function. First get_* the current values, change some of
them and use set_*
to activate the modified settings.
>
> 4) *sctp_getAssociatinParams(), *sctp_getInstanceParams():
> I'd prefer if the result is written in the memory of the ULP and not in a
> memory allocated by SCTP and released by ULP.
> It should be no problem, because the size of the result ist fixed.
[Tuexen Michael] This is much better than the way we do it now.
> 5)*sctp_status(),
> Here the same point as at 4), but the problem is probably the undefined
> length of the result of sctp_status().
> Also the ULP has to free not only the memory for result-structure, but also
> for *destinationAddresses, *SRTT, *RTO, ...
> Here I would suggest that you return the status for only one destination
> address. It is up to the ULP to run it several times for the various
> destinations. I think that makes it easier for both sides.
> Also the strings should be limited to avoid a release for every string.
>
> Here my proposal:
>
>
> typedef struct
> {
> unsigned short association_state;
> unsigned short number_of_dest_addresses;>
> unsigned short AddressIndex;
> unsigned char destinationAddress[50];
> unsigned short outstreams;
> unsigned short instreams;
> short path_state; /* PM_ACTIVE 0, PM_INACTIVE 1
> */
> unsigned int SRTT; /* im msecs
> */
> unsigned int RTO; /* im msecs
> */
> unsigned int currentReceiverWindowSize; /* from FlowControl
> */
> unsigned int currentCongestionWindowSize;
> unsigned int noOfChunksInSendQueue;
> unsigned int noOfChunksInRetransmissionQueue; /* from ReliableTransfer
> */
> unsigned int noOfChunksInReceptionQueue; /* from StreamEngine ?
> */
> }
> SCTP_AssociationStatus;
>
> int sctp_status
> (unsigned int associationID,
> short path_id, /* -1 for primary path, else address index
> to be taken */
> SCTP_AssociationStatus *status);
[Tuexen Michael] I would suggest to split it in two funtions:
get_assoc_state and get_path_state. Then everyting is of fixed
length.

> 5) sctp_associate()
> You forgot the parameter "pointer to ULP data".
[Tuexen Michael] Hmm, it will be in the comm_up. So should we have
it twice?
[Tuexen Michael]
> 6 ) Constants / Typedefs:
> Please don't beat me for this very formal comment and it is not important
> at all: Could you add the letters "SCTP_" in front of all the externally
> visible definitions, structs ... (e.g. SCTP_PATH_OK instead of PATH_OK) in
> sctp.h? (here we have very critical guidelines restricting "namespace
> pollution"...)
[Tuexen Michael] Good point.
> In general your naming conventions are clear and make it easy to understand
> the code...
>
> Thanks and
[Tuexen Michael] Thank you very much for your comments.
> Viele Gruesse
> Wolfgang
>
> **************************************
> Wolfgang Schrüfer SIEMENS AG
> ICN WN CC EKJ 14 TEL: 722-61646
> mailto:Wolfgang.Schruefer AT icn.siemens.de
> **************************************
>
> > -----Ursprüngliche Nachricht-----
> > Von: Michael Tüxen
> > [SMTP:Michael.Tuexen AT micmac.franken.de]
> > Gesendet am: Donnerstag, 22. Februar 2001 19:35
> > An:
> > Betreff: [SCTP-Discussion] Request for comments: API for SCTP 1.0
> >
> > Dear all,
> >
> > please find attached the sctp.h file for the version 1.0 of our
> > implementation.
> > I have also included a .pdf file describing the API made by Andreas
> > (thank you
> > very much!).
> >
> > I will send out a sample program tomorrow (a discard server) and next
> > week a more
> > elaborated echo server.
> >
> > Please send all your comments to this list!
> >
> >
> > Michael
> >
> > --
> > e-mail:
> > Michael.Tuexen AT micmac.franken.de
> > << Nachricht: Unbenannte Anlage >>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• RE: 2nd try: AW: [SCTP-Discussion] Request for comments: API for SCTP 1.0, Tuexen Michael, 02/26/2001

---

Archive powered by MHonArc 2.6.19+.