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)
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to