SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] sctp enhancements


Chronological Thread 
  • From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
  • To: discussion AT sctp.de, "Jim Wimberley" <rrjames AT nortelnetworks.com>
  • Subject: Re: [SCTP-Discussion] sctp enhancements
  • Date: Tue Feb 27 18:13:01 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University of Essen, Germany

On Friday 23 February 2001 05:07, Jim Wimberley wrote:
> Thanks for all your effort Michael and Andreas. I appreciate it. This code
> is really helpful for exploring SCTP.

Hi Jim,

sorry if it took so long to answer this -- I wanted to address
a few points and your questions. Your comments are warmly
welcomed.

> distribution.c:
> * method: mdi_receiveMessage
> -only call adl_sockunion2str if you really are going to log
> that address - would have to tie that into the log message that prints
> it
> * method: mdi_send_message
> -only call adl_sockunion2str if you really are going to log
> that address - would have to tie that into the log message that prints
> it
>
> globals.h:
> * modify the event_log* and error_log* defines so that the "am I going to
> print this" check comes before the actual log method. This prevents things
> like inet_ntoa (adaption.c - dispatch_event) from being evaluated when they
> aren't going to be logged.
> For example, convert:
> #define event_log(x,y) event_log1((x), __FILE__, (y))
> to
> #define event_log(x,y) if ((x) <= CURRENT_LEVEL) event_log1((x),
> __FILE__, (y))

Okay, that will go into the next release.
Performance was not primary goal, and I know a few other "weak" spots -
especially multiple copying for anything that uses a list. We decided
early in the project, to use a generic list hamdler (which after all,
works fine ;-) but also copies *everything* when putting it into the
list. I checked performance once with a profiler, and was angry to find
that most of the time of a program is spent allocating and freeing
memory (besides logging, of course).

> On a separate topic, my wish list for the API is basically to expose a few
> details so that the stack can be more easily incorporated into some other
> existing event loop. This basically would be:
> * have a way of getting the opened fd's so that they can be added to
> an existing event loop

Well, apart from the UDP-file descriptors (which you get as a result from
calling sctp_register_udp_callback()), there is STDIN, which may be registered
or not (and shouldn't be the problem that you mean) there are now only
a maximum number of two raw sockets bound to the IP protocol id 132 (==SCTP)
and (in the future) up to two ICMP file descriptors for path MTU discovery
which we have currently disabled.
Shouldn't be at all a problem to add these to an API.

> * have the sctp_event_loop() be non-blocking

aOkay, we have added the function int sctp_get_events(void); in the
latest version, which is non-blocking (I figured this would be nice to
have :-)

> I have built the SCTP stack on Solaris 2.6 using the WorkShop Pro 4.2 suite
> of compilers. I had to make a couple of modifications and I will gather
> these up and submit them to the list shortly.

Great ! At one time we compiled all this stuff on Slowlaris (x86 based) but
then dropped it, as no one seemed interested any more.

> I know you just added DOC++ support, but have you seen Doxygen? It seems to
> provide more functionality and can generate useful information without
> having to modify your source at all. Of course, like DOC++, the
> documentation benefits from commenting the code in specific ways. FYI:
> http://www.stack.nl/~dimitri/doxygen/index.html

I will have a look at it, and have already seen it.
What is the advantage/effort to change it ?
--

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




Archive powered by MHonArc 2.6.19+.

Top of page