Chronological Thread 

< Chronological >      < Thread >

---

Thanks Andreas,

please see below ...

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 18:29
> An:
> discussion AT sctp.de;
> Schruefer Wolfgang
> Betreff: Re: AW: [SCTP-Discussion] Update on API definition (sctp.h)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday, 28. February 2001 17:34, Schruefer Wolfgang wrote:
> > 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.
>
> Yes, you are right, and I regret that. The return values are neither very
> consequent, nor do they always say what happened. I have tried to
> give comments in the documentation, though, and for now I will not
> change that (because I would have to change more then throughout the
> entire source code), and there are more important things to be done
> before that.
>
> If you send me a couple of small (!), clean easy to understand patches
> (after release of a version 1.0) though, I am willing to change that,
> though.
>
> > 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);
>
> Well, again, there are much more important things to be done first.
>
>
[Schruefer Wolfgang]

Please do not misunderstand me. My intention is, that you suggest a vision of
an error reporting mechanism in the API, not the implementation.
Reporting mechanisms might be
a) return in an errorcase just -1 and set errno with common errorvalues from
errno.h (I wouldn't prefer that)
b) return in an errorcase just -1 and set errno with sctp-specific values (I
wouldn't like that too)
c) return in an errorcase negative values in the way suggested above
d) ...

The implementation can be done whenever you want.
At the moment, I've seen mostly the values -1, 0 and 1 to be returned.
So at the moment it would be enough to define e.g

/* specific error return values will be added in the future */
#define SCTP_SUCCESS 0
#define SCTP_UNSPECIFIED_ERROR -1
#define SCTP_SPECIFIC_FUNCTION_ERROR 1

These values are not wrong and there should be no big effort to implememement
it.
And in the future this list can be extended according the implementation ...



> > 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 ...
>
> Well, first thing will be to get rid of the dll_main.c module (to avoid
> copying multiple times).
> And for that I would start by creating a unified data structure for a
> chunk, that will be used in the streamengine-module, and other
> modules that handle the real "data flow" (i.e. flow-control, reliable
> transfer, bundling etc.)
> So, really for that I have to start off with the stream-engine and>
> that means: rewrite it. Which I will do later, because I do not entirely
> understand the code that has been written there.
>
> > 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
>
> I would suggest doing the above mentioned changes, and then look
> with a profiler, where performance hot spots are.
> THEN these would be attacked...actually at this stage of the implementation
> it would be way too early to start optimization.
> I know that at least 50% of the performance is simply wasted by
> unnecessarily copying and allocating/deallocating memory.
>
[Schruefer Wolfgang]
OK, I think this ideas are for a later step.

Just to avoid misunderstanding:

My intention is not an internal performance-improvement.

The idea is, that the memory, which is allocated by ULP will be
released again by ULP.
(Here we have ULPs that handle data in memory buffers, which are not
allowed to be freed by SCTP ).
Therefore a callbackfunction to return the datapointer (probably with
context...) is necessary.
And the same for the IP-adaption-layer (I was told, in the SOLARIS
kernal is a zero-copy IP-interface).

> > 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.
>
> Okay, agreed.
>
[Schruefer Wolfgang] Thanks!

> > 4) ulpCallbacks: sendFailureNotif instead of sentFailureNotif
> Yup, well.... that must have been written on a tired evening :-)
>
> 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
> -
> ----------------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE6nTVPd2Uw+xBvGUIRAg0kAJ4mTN5pKyJpFbttD/EIKCwztiN8cwCfSEEx
> NhholspqlRF7nzTSp71BGDw=
> =3hIt
> -----END PGP SIGNATURE-----

---

• AW: AW: [SCTP-Discussion] Update on API definition (sctp.h), Schruefer Wolfgang, 03/01/2001
  • [SCTP-Discussion] Another Update on API definition (sctp.h), Andreas Jungmaier, 03/01/2001

---

Archive powered by MHonArc 2.6.19+.