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.
|
