search

aeternity / protocol

Specification of the æternity blockchain protocol
https://docs.aeternity.com/protocol
206 stars 76 forks source link

where is the framing? #53

Closed vans163 closed 5 years ago

vans163 commented 6 years ago

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 commented 6 years ago

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

hanssv commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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