Chronological Thread 

< Chronological >      < Thread >

---

Title: RE: [SCTP-Discussion] sctp enhancements

> -----Original Message-----
> From: Andreas Jungmaier [mailto:ajung AT exp-math.uni-essen.de]
> Sent: Tuesday, February 27, 2001 12:03 PM
> To: discussion AT sctp.de; Wimberley, Jim [CAR:5Z60:EXCH]
> Subject: Re: [SCTP-Discussion] sctp enhancements
 
<SNIP>
 
> 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.

No problem on the delay.

<SNIP>

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

Yeah, I had just taken a quick look at it in a profiler and noticed those
few items accounting for a large percentage.

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

Cool.

> > * 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 agree with you! Are there guidelines as to how often this should be called
to ensure that the timers are serviced?

> > 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'll wait and submit them against version 1.0 as Michael suggested.

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

Basically, for me, it was a few things:
* you can generate very useful information on your code without doing
  any modifications to your code - it can generate three graphs:
  inheritance (for C++), collaboration (for C++) and an include
  dependency graph
* everything is hyperlinked (including graphs) and you can even get it
  to incorporate your source code as part of the documentation and the
  type & method names are hyper-linked in there as well
* it has a very active user discussion list and seems to have frequent
  updates and enhancements

It allows you to comment things in a certain style to get the generated
documentation to appear in a certain format and I think it even
understands DOC++ style comments. I'm still exploring these aspects.

I was just impressed that you could download it, point it at your source
and get useful information - just as a starting point.

Thanks,
Jim

---

• [SCTP-Discussion] sctp enhancements, Jim Wimberley, 02/23/2001
  • Re: [SCTP-Discussion] sctp enhancements, Michael Tüxen, 02/23/2001
  • Re: [SCTP-Discussion] sctp enhancements, Andreas Jungmaier, 02/27/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] sctp enhancements, Jim Wimberley, 02/25/2001
  • RE: [SCTP-Discussion] sctp enhancements, Jim Wimberley, 02/28/2001

---

Archive powered by MHonArc 2.6.19+.