On 6/2/21 4:14 PM, Xin Long wrote:
On Wed, May 26, 2021 at 11:38 AM Duzan, Gary D via tipc-discussion
<tipc-discussion@lists.sourceforge.net> wrote:
I'm in the process of enhancing a TIPC DGRAM-based RPC-ish service to
include TIPC STREAM transport for larger messages. To simplify configuration, I
have the server process(es) bind() the same type/range for both DGRAM and
STREAM sockets (poll()ing to see which have incoming requests), then choose
which to use on the client. This seems to work on most of my Linux systems
(RHEL-8, Ubuntu 20.04/21.04, Fedora 34, Debian 11), but on my Debian 10 system
(4.19.181-1 kernel) I am seeing messages from a DGRAM client appearing on an
accept()ed STREAM socket on the server. I have confirmed that the client is not
sending anything on a STREAM socket, and the message received by the server is
formatted as a DGRAM message (without the message framing header).
When you start two scoket on the server: DGRAM and STREAM, in the
client's nametable there will be 2 sockets with different portids:
# tipc nametable show
Type Lower Upper Scope Port Node
18888 17 17 cluster 4063960415
18888 17 17 cluster 1106254118
When the client calls sendmsg()/connect() to send msg to the server,
it will choose one of them by the rule of "local, closest-first or
round-robin".
The client doesn't know if the peer is a DGRAM socket or STREAM
socket. In your case, it should go round-robin.
Without this commit:
commit 25b9221b959483f17c2964d0922869e16caa86b5
Author: Jon Maloy <jon.ma...@ericsson.com>
Date: Fri Sep 28 20:23:21 2018 +0200
tipc: add SYN bit to connection setup messages
The SYN msg for STREAM is no different from the DATA msg for DGRAM.
that's what you're seeing in kernel-4.19
Debian isn't a target platform for production, so I don't need a specific
fix, but it is still surprising and a bit disturbing. Was this a known problem
with the 4.19 kernel? Are there particular reasons why using this pattern is a
bad idea?
I think it may not work as expected if you create 2 different types of
TIPC sockets binding to the same address.
At least on the latest kernel, once the DGRAM client chooses the
STREAM socket, the DATA msg will be dropped.
Thanks.
Exactly. Contrary to UDP vs TCP, TIPC is only one protocol, so you
cannot bind the same service type/instance to different socket types
without risking problems.
The SYN bit will prevent a connection from being established with a
socket of the wrong type, but it will not stop the binding table lookup
from selecting such a socket, since it knows nothing about socket types.
I am actually surprised that this works even on the non-Debian machines.
Maybe the secondary lookup mechanism is saving the day.
This could of course be fixed without too much effort, but the question
is if that is the right way to go. At least we would have to carefully
consider possible compatibility issues.
Would it be a problem for you to just choose different service types/ranges?
///jon
Thanks.
Gary Duzan
FIS - GT.M Core
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
