Date: Tue, 26 Oct 2004 06:40:05 -0400 From: Randall Stewart <randall@stewart.chicago.il.us> 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: <417E2985.2070609@stewart.chicago.il.us> 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
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. > > - 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) > > 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) > > Thanks and sorry if you feel my previous comments were insulting... > ---- > Suzuki-san: None of us on the SCTP team took your comments as insults ... we all want software with no bugs.. but it is perfectly understandable that if you don't get any bug reports you would feel no one is using it... As to compilation errors... it is difficult for me since when I prepare a patch of course I compile it but often times it takes many weeks for one of the KAME team to find the time to apply it.. this then causes a possiblity that some other changes made by KAME will make it uncompilable... or for that matter a change that KAME makes can cause SCTP not to compile and I would not have a chance to see such an issue... I am sorry I cannot help more :-0 Today I will finish running down a couple of "extra-shutdown's" and a case where no HB happens... (these are my reported bugs that are left.. nothing serious ... just a couple of strange behaviors)... Once I am done with that I can do my performance testing and then on to loading 6.0 :-D R -- Randall Stewart 803-345-0369 <or> 815-342-5222(cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?417E2985.2070609>