[Tipc-discussion] [Fwd: TIPC status March 2004]

[Jon M. <jon...@er...>]

  I sent this mail to cgl_specs and cgl_discussion.
For those of you who are not at these lists...

Cheers /jon

Hi all,
As there has been some questions about the status of TIPC recently,
I will give a brief summary here.

Large parts of the code has been rewritten over the last months, both
to accommodate the Linux kernel community with regards to code style
and more, but also to simplify and make it more maintainable in general.

The major changes are the following:

1: Code and directory structure. I now looks much more like what you would
    expect from linux kernel code. The need for continuous support for 
2.4, and
   realizing that the directory structure at SF does not have to be the 
same as the
   the one we use for the code to the kernel tree, made me add a couple of
   subdirectories, however. We will probably need a script to select the 
correct files
   for each targeted kernel tree.

2: Basic things such as memory management, lock handling and
    debug support has been completely rewritten. We now rely entirely on
    the linux native memory management. We also have a much finer lock
    granularity than previously, and the debug support has been greatly
    simplified, still without loosing the good parts of it.

3: The total source code volume (14000 lines) and module size (132 kbyte 
stripped)
    has been reduced, and there is potential for more.

4: The API has been rewritten, and is now as conformant to POSIX as I 
think it can
     be. We support SOCK_STREAM, SOCK_SEQ_ACKET, SOCK_RDM,
    SOCK_DGRAM, and connections can be established in two different, 
compatible
    ways: a TCP-style setup scheme and the traditional "non-protocol 
message" TIPC
    style. There is also a kernel-internal transport API, availabe for 
drivers, upon which
    the socket API is implemented.

5: We have modified the protocol header and added the framwork for providing
    reliable multicast, among other things. We have also added an 
"unreliable transfer
    mode" which can be set per socket. This makes it possible tho throw 
way e.g. tunneled
    IP-messages during overload (e.g. during DOS-attacks). The 
functionality for reliable
    multicast is not complete yet, though. A low-cost socket-to-socket 
flow control support
    has also been added.

6: We are also working on an (optional) distributed management 
functionality,
    making it possible to interrogate and change configuration setting 
in TIPC via
    the /proc file system on on one of the cluster nodes.

Despite all these changes I have taken great care to maintain a high 
degree of
code portability, albeit very much on Linux' conditions. Structures and 
function
names (spin_lock_bh, sk_buff etc) used are the Linux ones, but they should
be easily remappable to other OS-es by means of a few simple macros, not
by changing a lot of  source code files.

The code is now back to a state where it is working basically on both 
Linux 2.4 and
Linux 2.6. But some parts, such as the management functionality and the 
SOCK_STREAM
interface have not been tested yet.  This will be done during April.

I have also spent some time on pushing TIPC within IETF.
At IETF-59 in Seoul I presented the contents of an  Internet draft
(http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt) where The TIPC
features, old and new ones, as well as the protocol are described.
The presentation was received with great interest, but a lot remains to 
be done
before IETF will accept it as a standard.

Finally: I am planning to announce TIPC at the LKML within short.
I would very much appreciate feedback about functionality, code, protocol
and anything else that can contribute to make TIPC better.

Regards /Jon Maloy

 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.