Chronological Thread 

< Chronological >      < Thread >

---

About the error codes.

Why not use positive numbers and a range above the values used by errno.
That way one can mix the values in one variable and can figure out later
where the error comes from.

You should
#define SCTP_ERRORS_START
and
#define SCTP_UNSPECIFIED_ERROR SCTP_ERRORS_START+1
...

Asumiong that numbers are only of local interest and not go to the network.

> -----Original Message-----
> From: Schruefer Wolfgang
> [mailto:Wolfgang.Schruefer AT icn.siemens.de]
> Sent: Wednesday, February 28, 2001 5:35 PM
> To:
> discussion AT sctp.de
> Subject: AW: [SCTP-Discussion] Update on API definition (sctp.h)
>
>
> Hi Andreas,
>
> if you really want to hear more comments, I'll try my best...
>
>
> 1) Error Codes
> These are not very good supported yet.
> There should be sctp specific errorcodes (via #define or
> typedef enum),
> e.g.:
> #define SCTP_SUCCESS 0
> #define SCTP_UNSPECIFIED_ERROR -1 /*look at errno*/
> #define SCTP_ASSOC_NOT_EXISTING -2
> #define SCTP_PATH_NOT_EXISTING -3
> #define SCTP_INVALID_ADDRESS -4
> #define SCTP_LACK_OF_RESOURCES -5
> #define SCTP_SEND_QUEUE_FULL -6
> #define SCTP_WRONG_STATE -7
> #define SCTP_INVALID_PARAMETERS -8
> #define ...
>
> And (as "i-Tüpfelchen") you provide for error-reporting a
> stringified representation by a new helper function, e.g.:
> char * sctp_errcode2string (int);
>
>
>
> 2) Memory Management
>
> Goals:
> - no memory copy at the interfaces to ULP and IP (already implemented)
> - clear memory assignement to one specific layer.
> - usage of different memory pools might be necessary e.g. for
> protection mechanisms, cache behaviour, interprocess communication ...
>
> Therefore I would divide the memory in 3 parts:
> I) ulp_memory used by SCTP and ULP
> II) network_memory used by SCTP and IP-layer
> III) internal_memory
>
> Realisation:
> Instead of malloc() and free() seperate functions should be
> used (which do here just malloc() and free()), e.g.:
>
> sctp_ulp_malloc() /*for user data only, provided via
> SCTP_ulpCallback */
> sctp_ulp_free() /*for user data only, provided via
> SCTP_ulpCallback */
> sctp_network_malloc() /*for IP-packets only, provided by
> adaptation.c */
> sctp_network_free() /*for IP-packets only,
> provided by adaptation.c */
>
> malloc() or sctp_internal_malloc() /*for the rest,
> provided by adaptation.c */
> free() or sctp_internal_free() /*for the rest,
> provided by adaptation.c */
>
>
> 3) sctp_associate(): (again)
> parameter "pointer to ULP data"
> You said it's trivial to implement, so I think you should do
> it. It is easier for the ULP to provide it twice than to
> search through all its associations.
>
> 4) ulpCallbacks: sendFailureNotif instead of sentFailureNotif
>
>
>
> to be continued ...
>
> Thanks and
> 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: Andreas Jungmaier
> > [SMTP:ajung AT exp-math.uni-essen.de]
> > Gesendet am: Mittwoch, 28. Februar 2001 13:33
> > An:
> > discussion AT sctp.de
> > Betreff: [SCTP-Discussion] Update on API definition (sctp.h)
> >
> > Hello all !
> >
> > After looking at Michaels comments, I have decided to change,
> > well, quite a few things (mainly names) -- knowing that I have
> > "opened Pandoras box" and will have to change the names throughout
> > the library ;-)
> >
> > Notwithstanding, I would like to invite more comments, so
> > please: "Speak up now and not when it's too late !" :-)
> >
> > Anyway, I think that this looks much better now, we have got
> > rid of a few things that were not nice, e.g. there are no
> more functions
> > now, where the library has to allocate memory, which the
> user would have
> > to free (as in the old sctp_status()), and the old sctp_status
> > function has been split up into three functions that are able to
> > read status values from a SCTP instance, and certain association,
> > or a certain path within an existing association.
> > These use all fixed size structures now.
> >
> > --
> >
> > Andreas Jungmaier
> >
> >
> --------------------------------------------------------------
> --------------
> > E-mail is insecure. It may be read by other people,
> modified in the
> > course of transmission, or even faked (see
> http://www.stopcarnivore.org) !
> > To protect your E-mail,
> use encryption programs, such as PGP or GPG,
> > which can be obtained for free from http://www.gnupg.org !!!!>
> >
> --------------------------------------------------------------
> --------------
> > Andreas Jungmaier, Dipl.-Ing.
> > University of Essen email:
> ajung AT exp-math.uni-essen.de
> > Computer Networking Technology Group Tel. : +49 (0201) 183-7636
> >
> --------------------------------------------------------------
> --------------
> > PGP Public Key and Fingerprint: see
> http://www.exp-math.uni-essen.de/~ajung
> >
> --------------------------------------------------------------
> -------------- << Datei: sctp.h >>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion
>

---

• RE: [SCTP-Discussion] Update on API definition (sctp.h), Salbrechter Bernd, 03/07/2001
  • Re: [SCTP-Discussion] Update on API definition (sctp.h), Andreas Jungmaier, 03/07/2001

---

Archive powered by MHonArc 2.6.19+.