You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not opposed to it, but it requires a protocol change (because the I2P addresses don't fit into the current addr variables) so it would have to wait until more protocol changes are gathered.
@jakobvarmose What an interesting proposition. I need to think about it but I'm inclined to agree with you. I'm redesigning the network system anyway, so it will be easier for developers to add new commands.
The "version" command won't be compatible with a different addressing scheme. However it probably isn't a big deal as the values from this command aren't really usable if using an anonymising layer.
The current net_addr specification also only allows 32bit streams and would have to be expanded to 64 to coincide with the rest of the protocol anyway. So I propose to merge these two attempts by creating a new command and a new data type that is both able to handle 64bit stream identifiers and a greater range of address types. Let's call it "addrv2" or "addr64". The data type would add a new field, addr_type, a varint representing an enum, bump the stream length from 32bit to 64bit and that of the "IPv6/4" field from 64 to 256bit (the length of an I2P identifier). Also it could change the "stream" field to an array, so that multi-stream node could be advertised more efficiently and make routing path discovery easier.
Activity
PeterSurda commentedon Mar 17, 2017
I'm not opposed to it, but it requires a protocol change (because the I2P addresses don't fit into the current addr variables) so it would have to wait until more protocol changes are gathered.
jakobvarmose commentedon Mar 18, 2017
Why not use a new protocol message named "i2paddr" that will include the I2P addresses. Then the old nodes would just ignore it.
PeterSurda commentedon Mar 18, 2017
@jakobvarmose What an interesting proposition. I need to think about it but I'm inclined to agree with you. I'm redesigning the network system anyway, so it will be easier for developers to add new commands.
PeterSurda commentedon Mar 19, 2017
The "version" command won't be compatible with a different addressing scheme. However it probably isn't a big deal as the values from this command aren't really usable if using an anonymising layer.
The current net_addr specification also only allows 32bit streams and would have to be expanded to 64 to coincide with the rest of the protocol anyway. So I propose to merge these two attempts by creating a new command and a new data type that is both able to handle 64bit stream identifiers and a greater range of address types. Let's call it "addrv2" or "addr64". The data type would add a new field, addr_type, a varint representing an enum, bump the stream length from 32bit to 64bit and that of the "IPv6/4" field from 64 to 256bit (the length of an I2P identifier). Also it could change the "stream" field to an array, so that multi-stream node could be advertised more efficiently and make routing path discovery easier.