IPFS ping protocol

Help Coding
11

Ok, according to this https://github.com/multiformats/multistream-select, you can also use ln\n at various points to get the available options.

I’ll use bold for received messages, italic for transmitted. Everything has a byte (varint) at the beginning, with the length of the message (including newline) written in binary. Lines are ended with newline i.e. \n.

So it seems that the handshake needs to be in form of:
/multistream/1.0.0
/multistream/1.0.0

Anything else fails: closes socket.

If we do the before described handshake, we can send ls. If we have the normal ipfs deamon, with encryption on, then we get the only option /secio/1.0.0, if not, we get /plaintext/1.0.0, which is what I got with my unencyrpted tests.

We have to repeat that back.

After we repeat that back, we send ls again. We get the only option, which is (again) /multistream/1.0.0.

We have to repeat that back.

After we repeat that back, we send ls again. We get two options, each in its own line, but sent in one piece. After the first byte indicating length (like any other message insofar) we get an another byte indicating the number of entries. Then each entry has its own preceeding byte for length.
/yamux/1.0.0
/mplex/6.7.0

With added extra bytes (including length, newlines):
\0x1D \0x02 \0x0D /yamux/1.0.0 \0x0A
\0x0D /mplex/6.7.0 \0x0A

  • \0x0A is new line
  • \0x1D is 29 which is the number of characters in the whole response (not counting this byte for length).
  • \0x02 is number of entries, 2 in this case
  • \0x0D is 13, which is the number of characters of /yamux/1.0.0 including new line.
  • \0x0D is the same thing just for mplex.

I didn’t notice the same behaviour with the ls executions before this one. Which points that possibly if the choice is only one, then number of entries is not given.

1 Like