Date: Tue, 26 Oct 2004 09:44:41 -0500 From: Peter Lei <peter.lei@ieee.org> To: SUZUKI Shinsuke <suz@kame.net> Cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler Message-ID: <417E62D9.2080807@ieee.org> In-Reply-To: <x78y9uhxa1.wl%suz@crl.hitachi.co.jp> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <x7r7nrgsol.wl%suz@crl.hitachi.co.jp> <4179ACB8.4020108@ieee.org> <x78y9uhxa1.wl%suz@crl.hitachi.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] SUZUKI Shinsuke wrote: >>>>>>On Fri, 22 Oct 2004 19:58:32 -0500 >>>>>>peter.lei@ieee.org(Peter Lei) said: > > >>While the SCTP API hasn't gone through last call, it's fairly >>stable and we have both "converted" many applications from TCP >>to SCTP using the sockets API, as well as had portability between >>the KAME SCTP stack and the linux stack for some test applications >>used at the last interop event (except for the standard sockets >>issues that one runs into even for TCP like no sin_length field >>in the sockaddr struct). >>I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. >>The major changes to our SCTP code when it gets committed into KAME >>has been that of code format/style. > > > What I found was the following two issues. Although these two are > technically quite trivial, what I was fearing was a lack of report to > KAME, since this may mean a lack of KAME-SCTP users. > > - inconsistency between KAME specific kernel code and SCTP leads > to an kernel compilation error. > Of course, it's a technically trivial bug and our own bug. This might be due to the fact that the SCTP CVS repository code is sometimes more up-to-date than the KAME one, so we can get out of sync. Randy releases patch kits based on some point in the KAME repository and we know it compiles (and runs) fine at that point, but by the time it is committed into the KAME repository, things may have changed. > - including SCTP in getaddrinfo() causes 'configure' script error > in many ports applications. > This is also a trivial problem, and maybe specific to KAME SCTP. > And some of such ports are already fixed when I encounter this > problem. > (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) Ok... I understand what you mean by compile errors now. I haven't done too much with existing apps but haven't run into this at all much yet. > But now I understand that lack of report does not mean a lack of > testing users (since SCTP-lovers seems communicating directly to your > team). So I can be much more optimistic now, and don't object to > merging it into -current, since such trivial bugs can be fixed easily > in -current. (I myself haven't tested SCTP very well, so I cannot > comment on its stability itself. But at least, SCTP does not seem to > affect the behavior of other protocols) I understand... the lack of bugs filed might lead you to believe the code isn't being used at all. > Thanks and sorry if you feel my previous comments were insulting... No, no... not at all. I just wanted to be sure that people know that the stack is indeed being used and that people are finding bugs and we are fixing them :-) regards, --peter > ---- > SUZUKI, Shinsuke @ KAME Project > [-- Attachment #2 --] 0 *H 01 0 + 0 *H 00: 0 *H 0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0 040317215633Z 050317215633Z0D1 0 UThawte Freemail Member1!0 *H peter.lei@ieee.org0"0 *H 0 w@@YPJeM+rĩOY&P- wͿs'c k5fDb9J="ѷ&7bM. ː/,m$; -<8k1\ä :nnhMof;b |5؆4Ť0H;eR ;3QxZ==%=?-;-o?*=œS{jVM~drVM4 m /0-0 U 0peter.lei@ieee.org0 U 0 0 *H :ZNG.=oU 5P%že<z%EeH] gSjd(K1uu|/P䏔? e=ŴCVzJa1aai101#~00: 0 *H 0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA0 040317215633Z 050317215633Z0D1 0 UThawte Freemail Member1!0 *H peter.lei@ieee.org0"0 *H 0 w@@YPJeM+rĩOY&P- wͿs'c k5fDb9J="ѷ&7bM. ː/,m$; -<8k1\ä :nnhMof;b |5؆4Ť0H;eR ;3QxZ==%=?-;-o?*=œS{jVM~drVM4 m /0-0 U 0peter.lei@ieee.org0 U 0 0 *H :ZNG.=oU 5P%že<z%EeH] gSjd(K1uu|/P䏔? e=ŴCVzJa1aai101#~0?0 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 030717000000Z 130716235959Z0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA00 *H 0 Ħ<UsUNʙZ hup [v :aQP 0cZ,p+Z?qV˯< 6$*+w=+>@dקe*TH<a@ dr` 00U 0 0CU <0:08642http://crl.thawte.com/ThawtePersonalFreemailCA.crl0 U 0)U "0 0 10UPrivateLabel2-1380 *H HP . fgCL!6 -6/ P p<ab:~ t%Pb'qW%ݩ9 Oe_N4[5MwV!x!5$ F]_eO1;070i0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA 0 + 0 *H 1 *H 0 *H 1 041026144441Z0# *H 1u,*`Co iX^V0R *H 1E0C0 *H 0*H 0 *H @0+0 *H (0x +71k0i0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA 0z *H 1ki0b1 0 UZA1%0#U Thawte Consulting (Pty) Ltd.1,0*U#Thawte Personal Freemail Issuing CA 0 *H L72Xp11`r?-c =0# oUXZ_Y͖eZzy _an{<TBZn]4=藰}9z#I@v-õ0}}>}~o/6-O+)yΣuVmF|cBĐAc8w#,\g `eЄ+&ĞD/ XgJqf ;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?417E62D9.2080807>