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