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