Hi all,
I have checked in an "unstable" TIPC, merged with Guo's and Ling's
multcast code. (I had to comment out that code, though, there seems
to be something missing that makes it impossible to compile.)
The user API has had another overhaul, and I think the socket
interface is now a lot closer to Posix compliance.
From now on a user must strictly define which kind of socket
he wants: SOCK_RDM (for connectionless communication)
SOCK_SEQPACKET or SOCK_STREAM. The sockets
will behave the way people expect them to: To set up/shut down
a connection, use connect() and shutdown(), and then send/receive
data the way you are used to. But: It is still possible to do setup by just
sending a name addressed message to the accepting port. Also, it
is possible to do local connect()/disconnect() via ioctl's, so the current
semantics is fully preserved, for those who want that option.
I implemented use of the MSG_PEEK flag for SOCK_SEQPACKET and
SOCK_RDM, but I find this rather unsatisfactory, so I invented a new
flag for recv(): MSG_PEEP.
This behaves as the TIPC API always did: if the given buffer is too short,
it is returned with the first four bytes containing the length of the
pending
message. If this flag is not used, a recv() will behave according to
standard,
i.e. to discard the remainder of the message.
The code is less stable than the previous version, and some of it
(SOCK_STREAM) is not even tested, but I still decided to check it
in so that you can see what the interfaces and socket adaptation look
like now, and possibly do some testing.
I am going to Seoul (IETF-59) tomorrow, and may be difficuly to reach next
week, but you are welcome to try. I can be reached at +1 514 576 2150, or
as secondary option +47 928 09 576. And I read email, of course.
Regards /Jon
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.
|
