@Giulio2002 and I are trying to understand how to decode packets on the Req/Resp domain.
Currently, when a packet is received, the prefix is stripped from the front of the slice: here.
The logic for the amount of bytes to remove from the front of the packet is:
if _, ok := val.(*cltypes.LightClientBootstrap); ok {
return make([]byte, 7)
}
if val.SizeSSZ() <= 16 {
return make([]byte, 1)
}
return make([]byte, 6)
or in other words, if it is a LightClietBootstrap message -> remove 7 bytes, if the size of the deserialized object is <=16 bytes -> remove one byte, otherwise -> remove 6 bytes.
As we are expanding the handlers on the req/resp domain, we would like to better understand how to determine the size of that prefix.
#5878 has a minimal working example of this with a test finality update packet:
we read the first six bytes:
// Read first six bytes.
r := bytes.NewReader(fullPacket)
r.Read(make([]byte, 6))
and then we are able to decompress and decode the SSZ encoded object. If we do not trim the first six bytes, we get the following error unable to decompress data: snappy: corrupt input. If we do trim the first 6 bytes, then we get the decoded object:
decoded object: &{
AttestedHeader:0xc00015c230
FinalizedHeader:0xc00015c2a0
FinalityBranch:[[52 99 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [65 101 88 22 4 244 176 47 93 194 65 37 79 221 228 105 165 92 142 193 186 58 67 20 134 241 135 34 122 125 115 57] [172 122 65 185 199 105 189 49 177 241 177 210 33 99 244 214 26 95 84 189 174 224 193 54 236 63 221 184 78 109 127 253] [221 85 168 161 105 38 209 149 105 3 159 122 244 254 178 255 91 77 120 187 125 142 51 120 0 141 50 174 6 219 151 239] [0 85 229 188 59 64 96 194 166 103 55 135 128 213 137 87 28 183 254 10 242 76 181 154 34 69 191 188 199 55 40 100] [95 23 207 224 0 161 38 165 131 206 255 211 250 35 98 251 173 131 104 203 253 249 177 151 226 215 171 138 240 89 169 36]]
SyncAggregate:0xc00020e080
SignatureSlot:5007072
}
@Giulio2002 and I are trying to understand how to decode packets on the Req/Resp domain.
Currently, when a packet is received, the prefix is stripped from the front of the slice: here.
The logic for the amount of bytes to remove from the front of the packet is:
or in other words, if it is a LightClietBootstrap message -> remove 7 bytes, if the size of the deserialized object is <=16 bytes -> remove one byte, otherwise -> remove 6 bytes.
As we are expanding the handlers on the req/resp domain, we would like to better understand how to determine the size of that prefix.
#5878 has a minimal working example of this with a test finality update packet:
we read the first six bytes:
and then we are able to decompress and decode the SSZ encoded object. If we do not trim the first six bytes, we get the following error
unable to decompress data: snappy: corrupt input. If we do trim the first 6 bytes, then we get the decoded object: