See my 3rd point below :-) -----Original Message----- From: Avner Ben Hanoch Sent: Wednesday, June 29, 2016 16:59 To: Ceph Development <ceph-devel@xxxxxxxxxxxxxxx> Subject: msgr2 protocol comments Hi, Reading documents and discussions about msgr2 I found it very exciting. Few comments that I have at this phase: 1 - We might want to sharply clarify the terms client and server. With msgr2 protocol, several streams can be multiplexed into one TCP connection. If I understand correctly, these streams are not forced to be in the direction of the TCP connection - means the TCP client (initiator) can be either the stream client (initiator) or the stream server (acceptor). Hence, it might worth to have more subtle definitions and to use each one were appropriate 2 - it is not clear to me which step is at connection level and which step is at stream level. For example, I would expect that Authentication will be at connection level - once for all its streams. However, it is defined with the frames after the banner phase where it is considered the stream level 3 - Since msgr2 is based on frames, and since it "knows" to continue a session even after a TCP disconnect - all these and more make msgr2 very appropriate for connectionless and/or datagram based transports (like UDP / RDS / and even XIO). Hence, I suggest to be more general in the definitions... to define a connection based on its tuple (source ip, source port, destination ip, destination port) and not necessarily based on TCP connection. This way we can make the implementation of msgr2 with maximum flexibly and maximum shared code between all future messengers. Regards, Avner -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
