Date: Sun, 05 Nov 2006 09:15:14 -0500 From: Randall Stewart <rrs@cisco.com> To: Randall Stewart <rrs@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet sctp_bsd_addr.c sctp_crc32.c sctp_indata.c sctp_input.c sctp_output.c sctp_pcb.c sctp_structs.h sctp_uio.h sctputil.c sctputil.h src/sys/netinet6 sctp6_usrreq.c Message-ID: <454DF1F2.6050006@cisco.com> In-Reply-To: <200611051325.kA5DPIkb074516@repoman.freebsd.org> References: <200611051325.kA5DPIkb074516@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Randall Stewart wrote:
> rrs 2006-11-05 13:25:18 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/netinet sctp_bsd_addr.c sctp_crc32.c
> sctp_indata.c sctp_input.c sctp_output.c
> sctp_pcb.c sctp_structs.h sctp_uio.h
> sctputil.c sctputil.h
> sys/netinet6 sctp6_usrreq.c
> Log:
> Tons of fixes to get all the 64bit issues removed.
> This also moves two 16 bit int's to become 32 bit
> values so we do not have to use atomic_add_16.
> Most of the changes are %p, casts and other various
> nasty's that were in the orignal code base. With this
> commit my machine will now do a build universe.. however
> I as yet have not tested on a 64bit machine .. it may not work :-(
>
> Revision Changes Path
> 1.2 +7 -7 src/sys/netinet/sctp_bsd_addr.c
> 1.3 +1 -1 src/sys/netinet/sctp_crc32.c
> 1.2 +4 -4 src/sys/netinet/sctp_indata.c
> 1.4 +7 -5 src/sys/netinet/sctp_input.c
> 1.2 +9 -9 src/sys/netinet/sctp_output.c
> 1.4 +8 -8 src/sys/netinet/sctp_pcb.c
> 1.2 +5 -4 src/sys/netinet/sctp_structs.h
> 1.2 +8 -8 src/sys/netinet/sctp_uio.h
> 1.3 +35 -21 src/sys/netinet/sctputil.c
> 1.2 +2 -2 src/sys/netinet/sctputil.h
> 1.3 +5 -4 src/sys/netinet6/sctp6_usrreq.c
>
A few notes about this commit.. if your playing with SCTP
everything should work fine with a couple of cavets (besides
64 bit machines.. which may or may-not work :-0)
1) If you want to play with "mobility" type issues where you
can have addresses come and go dynamically by your SCTP
stack you need to:
a) bind all addresses (INADDR_ANY).
b) You need to enable the behavior with a sysctl
net.inet.sctp.auto_asconf..
c) This should enable you to do ifconfig inf new-addr netmask newmask
and the association you create with a peer will stay up and
reconfigure the addresses dynamically...
Why: Well the reason it is a sysctl and must be activated is that
currently the code needs some tweaking to make it so that if
you had 10,000 associations up and added an address you would
not sink the machine :-( ... In theory we need to move this to
a thread.. and/or to use the iterator (or both more like to help
keep supporting apple and other platforms that do not have
k-threads).
2) Paritial reliability is fully supported and can be accessed by
using the send options described in the sctp-sockets draft in
the IETF :-D
3) Authentication (sort-a like TCP-MD5.. but not requiring shared
keys.. they are optional) is also fully supported.. you may
use socket options to enable additional chunks (besides the
required dynamic addressing ones) to be auth'd. Note that if
you auth data, performance will drop to 1/5 of what it was :-0
Shared keys can be set also by socket option
(see the draft-ietf-tsvwg-auth .. soon to be RFC)... for more
details. Note also, that you MAY not work with older versions
that do not support the latest auth-draft (the one that finished
WG-LC).. they added the chunks being auth'd to the key material.
If you hit this problem (I don't any but BSD and IOS support this
but you never know).. there is a compile option that can get the
old draft behavior... send me an email in the "unlikely event of
a water landing" :-)
4) If you are deep into playing with "TCP emulation mode, you will be
turning on SCTP_EEOR on you socket (Explicit End Of Record). And
setting your partial delivery point to 1 byte. This is cool and works
gaining a bit of performance in the mix .. however there is currently
a bug I am chasing. If the peer is NOT in this same mode.. and is in
the more traditional.. implied-EEOR (where each send is considered a
message) and the PD-API point is NOT set (left to default).. when the
guy that is SCTP_EEOR mode closes the socket without sending the last
data with an explicit EOR.. the peer will get stuck.. waiting for
data. There is a missing wakeup somewhere that I need to find. All
other modes (EEOR -> EEOR), (NON-EEOR -> NON-EEOR),
(NON-EEOR -> EEOR) work fine.. its only the one case I have yet to
nail.. I will try to get this fixed (and approved by gnn) as soon
as I trace down this item.. I am hoping I can find it on my laptop
on loopback.. or debugging will be a bit of a challenge :-0
5) You are best to not compile in any options .. just option SCTP ...
however.. if you want to see LOTS of msgs on the console you can
add SCTP_DEBUG... then you can either play with the sysctl var:
net.inet.sctp.debug. This int is a bit mask that turns on various
prints in the code.. if you are a REAL glutton make it 0xffffffff
.. each bit has a different meaning... but please note I usualy
NEVER compile with this option.. it adds a LOT of
if(sctp_debug_on & MASK_VALUE) to the code... without it they
disappear from the code at compile time. The other option is
a socket option to set this value too... contact me offline if
you want to know it..
6) If you want to enable Sally Floyd's High Speed TCP Congestion Control
its a compile options option SCTP_HIGH_SPEED. In the future we will
be adding more "pluggable" congestion control with a varient of
Doug Leith's H-TCP as well as Sally's.. and make it a sysctl to
switch amongst the choices :-)
7) If you really really are a junky for fun, there are a set of various
logging utilites. You first start with SCTP_STAT_LOGGING options.
this enables a 80,000 entry chunk of memory and all the utilities to
log dynamically with minimal overhead (no locks, just an atomic op).
Once you turn this on, you must select one of the other logging
entries to get some real logs. There are things on cwnd/flight
blocking/locking.. and all sorts of things. I actually have some
tools where you can watch the cwnd/flight/rwnd in a conversation
between two machines over time graphically... you suck this data
out and then dump it into files which then can be plotted.. its
kinda-cool actually.. but you have to be a real junky to want
to play with this... if you are such a guy send me a private email
and I will send you code and further instructions.
8) I will try to figure out where libsctp.a should go (the extra SCTP
non-system call, system calls)... and a few select test tools.
(advice would be appreciated).....
You should, in theory, be able to take ANY TCP program and change
the sd = socket(AF_INET, SOCK_STREAM, 0) [the 0 is sloppy programming
in my mind now] and replace it with
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)
and your program should work.. there are equivilants to TCP_NODELAY
and other socket options (just change the TCP to SCTP :-D).
Note I usually use the one-2-many model.. which is gotten via
sd = socket(AF_INET, SOCK_DGRAM, IPPROTO_SCTP). This looks like
udp more than anything else.. You just send to who you want to
and if no assoc exists.. you will get one setup implicitly for
you (also carrying your first message piggyback on the 3rd leg
of the 4-way handshake) :-)
9) Tell me about anything strange please.. if there are issues (which
there may be even besides the 64 bit ones) I want to know about it
and get my small team working on fixing them. Most of the sctp geeks
will be at the IETF so any problems this next week can hopefully be
fixed fairly quickly :-)
Have fun and
Happy SCTPing :-)
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454DF1F2.6050006>