where is the framing?

[vans163]

Question, did you consider using msgpak or at worst json?

Question 2: were is the framing, over TCP the message can be sent as fragments requiring multiple receive calls, how do I know when I got the full message? Most protocols at the very least have the first 1-4 bytes (varint sometimes) specifiying the message length.

[sennui]

@vans163 yes we will go with msgpack. Wire protocol is coming soon, we need to polish that.

[hanssv]

Since msgpack has some quirks when it comes to deterministic representation RLP (https://github.com/ethereum/wiki/wiki/RLP) is used for serialization of objects and P2P messages. An overview of the sync protocol is HERE and the exact messages are documented HERE

[vans163]

Iv been following EoS and company, the P2P connections between light nodes is very useful to build all sorts of use cases. They accomplish it by having STUN/Turn like peer nodes to help establish these connections. But these solutions all use TCP (with TCP holepunch), a UDP solution would be really useful. Something like SCTP where the peer can select if they want a reliable+ordered, or unreliable channel.

[knarz]

Keeping as many nodes as possible in the p2p network is definitely a goal.

Something like SCTP, that allows both modes, would be nice but from a quick glance, SCTP seems like a bad candidate, though, given that it needs special drivers for both Windows and MacOS and would probably run into problems with middleboxes.

With that said, we will almost certainly end up using both TCP and UDP—or maybe something from the userland, QUIC-like.

[vans163]

@knarz Allowing TCP and UDP nat holepunching plus P2P connections would be awesome. Is there any confirmation on this? P2P connections + inchannel smart contracts can lead to some very interesting use cases.

My vote would be against QUIC. If someone wanted to implement quic and they have UDP available (with nat holepunch/p2p signalling), they can. QUIC is too complex and growing at its current stage, it would be problem ridden and time consuming.