Federation's other supernode addresses get transmitted in REGISTER_SUPER_ACK payload as a memcpy'ied replica of their n2n_sock_t representation. This could lead to communication difficulties if sender and receiver do not share the same endianess or apply different padding schemes in their way of (not) padding structs.
This can easily be solved by using the proper encode_sock() and decode_sock() functions, but it will break federation compatibility to 3.0.
While there basically are two clean options – solve it for 3.2 and break federation compatibility to 3.0 or wait till 4.0 to keep the protocol (faulty but) compatible among all 3.x versions – a third option comes to mind: Introduction of a crooked encode_sock_payload() (plus decode_...) trying to imitate the most common prevailing encoding and hence make sure it is used on all systems then.
I go for the third option unless I hear any other (convincingly presented) opinion.
Federation's other supernode addresses get transmitted in
REGISTER_SUPER_ACKpayload as amemcpy'ied replica of theirn2n_sock_trepresentation. This could lead to communication difficulties if sender and receiver do not share the same endianess or apply different padding schemes in their way of (not) paddingstructs.This can easily be solved by using the proper
encode_sock()anddecode_sock()functions, but it will break federation compatibility to 3.0.While there basically are two clean options – solve it for 3.2 and break federation compatibility to 3.0 or wait till 4.0 to keep the protocol (faulty but) compatible among all 3.x versions – a third option comes to mind: Introduction of a crooked
encode_sock_payload()(plusdecode_...) trying to imitate the most common prevailing encoding and hence make sure it is used on all systems then.I go for the third option unless I hear any other (convincingly presented) opinion.