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?

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 primaryAddressIndex;
unsigned char primaryDestinationAddress[50];
unsigned short outstreams;
unsigned short instreams;
;
unsigned char *destinationAddresses[][]; /* from SCTP-Control
*/
/* from PathManagement */
short *path_states; /* 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;






I dont't have a really good idea to solve this, e.g. a way would be to define
a value :
#define SCTP_MAX_STATUS_MEMSIZE 1024
The ULP has to allocate this memory and the pointer is added to the
parameter-list ...

5) sctp_associate()

) Constants / Typedefs:
To avoid the (very unlikely) case of two programs using the same definitions:
Could you add the letters "SCTP_" in front of the definitions (e.g.
SCTP_PATH_OK instead of PATH_OK)?
(here we have very critical guidelines restricting "namespace pollution"...)




Viele Gruesse
Wolfgang Schruefer

**************************************
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:
> discussion AT sctp.de
> 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!
>
> Happy SCTPing
> Michael
>
> --
> e-mail:
> Michael.Tuexen AT micmac.franken.de
> << Nachricht: Unbenannte Anlage >>

---

• AW: [SCTP-Discussion] Request for comments: API for SCTP 1.0, Schopp Michael, 02/26/2001
  • <Possible follow-up(s)>
  • AW: [SCTP-Discussion] Request for comments: API for SCTP 1.0, Schruefer Wolfgang, 02/26/2001

---

Archive powered by MHonArc 2.6.19+.