SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler

[SUZUKI Shinsuke]

>>>>> On Fri, 22 Oct 2004 19:58:32 -0500
>>>>> peter.lei at 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, Shinsuke @ KAME Project
_______________________________________________
freebsd-arch at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"