SCTP Discussions

Text archives Help


Re: AW: [SCTP-Discussion] Update on API definition (sctp.h)


Chronological Thread 
  • From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
  • To: discussion AT sctp.de, Schruefer Wolfgang <Wolfgang.Schruefer AT icn.siemens.de>
  • Subject: Re: AW: [SCTP-Discussion] Update on API definition (sctp.h)
  • Date: Thu Mar 1 11:12:02 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University of Essen, Germany

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

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

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

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



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

Archive powered by MHonArc 2.6.19+.

Top of page