Chronological Thread 

< Chronological >      < Thread >

---

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?

1b) delay: I'd prefer it as an AssocParam

1c) assoc/pathMaxRetransmits can be set also as AssocParam, do you really
want it twice (but why not ...)?

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?

Please can you provide an explaination of the flowcontrol-values?

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" ?

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.

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);


5) sctp_associate()
You forgot the parameter "pointer to ULP data".

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"...)
In general your naming conventions are clear and make it easy to understand
the code...

Thanks and

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

---

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

---

Archive powered by MHonArc 2.6.19+.