Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler
From: Peter Lei (peter.lei_at_ieee.org)
Date: 10/23/04
- Previous message: Poul-Henning Kamp: "REVIEW: handling kldload/kldunload of GEOM classes properly."
- In reply to: SUZUKI Shinsuke: "SCTP in KAME / Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Randall Stewart: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Reply: Randall Stewart: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Reply: Randy Bush: "Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler"
- Reply: SUZUKI Shinsuke: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 22 Oct 2004 19:58:32 -0500 To: SUZUKI Shinsuke <suz@kame.net>
I think this is because any bugs that are found are usually
communicated directly to us.
I think Randy has a better handle on how many people are using
this stack. I'm quite sure it is stable enough to go in to
-current.
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).
The same stack has also been ported to Mac OSX as a native kernel
build as well as an loadable/unloadble NKE w/a minor kernel change.
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 is the existing criteria for a measure of "stability"?
regards,
--peter
SUZUKI Shinsuke wrote:
>>>>>>On Thu, 21 Oct 2004 21:32:48 +0200
>>>>>>molter@tin.it(Marco Molteni) said:
>
>
>>SCTP in KAME is complete, stable and fully supported.
>>It is mainly developed by the SCTP RFC author, Randall Stewart.
>
>
> KAME Project haven't received SCTP-related bug report so much, and I
> think it's due to a lack of testers, SCTP-API standard, and SCTP-ready
> applications.
> #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP
> #application fails in compilation due to a change by SCTP. So it's
> #difficult to conclude that SCTP is already stable...
>
> So I'm not still sure if SCTP in KAME is complete and stable enough to
> merge into -current. (If someone can contribute to this kind of
> evaluation, it's quite appreciated, of course!)
>
> Thanks,
> ----
> SUZUKI, Shinsuke @ KAME Project
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
- application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature
- Previous message: Poul-Henning Kamp: "REVIEW: handling kldload/kldunload of GEOM classes properly."
- In reply to: SUZUKI Shinsuke: "SCTP in KAME / Re: Removing T/TCP and replacing it with something simpler"
- Next in thread: Randall Stewart: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Reply: Randall Stewart: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Reply: Randy Bush: "Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler"
- Reply: SUZUKI Shinsuke: "Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler
... >>to SCTP using the sockets API, as well as had portability between ...
>>The major changes to our SCTP code when it gets committed into KAME ... what I
was fearing was a lack of report to ... all want software with no bugs.. ...
(freebsd-arch) - Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler
... I think this is because any bugs that are found are usually ... While the SCTP
API hasn't gone through last call, ... the KAME SCTP stack and the linux stack for
some test applications ... I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP.
... (freebsd-net) - Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler
... I do get all the bugs reported to me directly.. ... I know of at least 4 sites
actively using the code and reporting ... are behind us (just like KAME is too)..
... I have not heard of any compile issues with SCTP and KAME.. ... (freebsd-arch) - Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler
... I do get all the bugs reported to me directly.. ... I know of at least 4 sites
actively using the code and reporting ... are behind us (just like KAME is too)..
... I have not heard of any compile issues with SCTP and KAME.. ... (freebsd-net) - Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler
... >>While the SCTP API hasn't gone through last call, ... >>to SCTP
using the sockets API, as well as had portability between ... >>The major changes
to our SCTP code when it gets committed into KAME ... (freebsd-arch)