WIP: WS2P v2
Merge request reports
Activity
rfc/0006_ws2p_v2.md 0 → 100644213 | api_version | 2 | u16 | 214 | nf_size | 1 | u8 | 215 | network_features | nf_size | specific | 216 | af_size | 1 | u8 | 217 | api_features | af_size | specific | 218 | ip_v4 | 4 | [u8; 4] | 219 | ip_v6 | 16 | [u16; 8] | 220 | host | host_size | utf8 | 221 | port | 2 | u16 | 222 | path | path_size | utf8 | 223 224 #### api_code interpretation 225 226 If api_size > 0 then `api_name` is a string utf8. 227 228 If api_size == 0 then `api_name` is an 8-bit binary value : -
De ce que je comprends, les API tiers sont là pour pouvoir déclarer des endpoints supplémentaires comme
ES_API.Quid des API tiers qui finissent par devenir des API du coeur ? Comment est prévu le comportement du réseau ?
Que se passe-t-il si un utilisateur déclare une API tiers nommée du nom d'un endpoint du coeur de réseau ?
Quid des API tiers qui finissent par devenir des API du coeur ? Comment est prévu le comportement du réseau ?
Si une API tiers deviens une API du cœur mais que WS2P ne connaît pas le nom associé, il demandera a l'ensemble des modules. le module en charge de l'API correspondante devra alors fournir le nom, a défaut de réponse, l'endpoint sera considéré comme invalide.
Que se passe-t-il si un utilisateur déclare une API tiers nommée du nom d'un endpoint du coeur de réseau ?
Alors ce n'est pas une API tiers. Le noeud de l'utilisateur reconnaîtra que c'est API du coeur et l'endpoint sera transmis aux modules. Le module gérant l'API en question pourra alors prendre en compte ce endpoint ou pas, mais ça appartient au module de l'api, ça ne concerne pas le cœur qui ne fait que relayer.
changed this line in version 23 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
232 | BASIC_MERKLED_API | 0x00 | 233 | WS2P | 0x01 | 234 | GVA | 0x02 | 235 | DASA | 0x03 | 236 237 #### network_features 238 239 The 16 bits represent booleans to define the presence or absence of 16 network features. WS2Pv2 defines only 4 features, the remaining 12 are undefined and are in anticipation of future Ğfeatures. 240 241 Network features : 242 243 | bit | feature | 244 |:---------:|----------| 245 | 0000_0001 | ip_v4 | 246 | 0000_0010 | ip_v6 | 247 | 0000_0100 | S | changed this line in version 7 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
274 WS2P v2 uses only 3 of 8 features. The 5 free bits can be used for future versions of WS2P. 275 276 ### Endpoint utf8 format 277 278 The utf8 format is used to display the endpoint in a human-readable format. It is also in this format that the user can manually enter an endpoint. 279 280 General utf8 endpoint format : 281 282 API_NAME VERSION NF1 .. NFn (AF1 .. AFn) IP4 [IP6] HOST PORT PATH 283 284 NF := NETWORK_FEATURE 285 AF := API_FEATURE 286 287 Example: 288 289 WS2P 2 S (DEFLATE LOW RBF) g1.durs.ifee.fr 443 ws2p -
Honnêtement le format human-readable je m'en fiche un peu, si tu a une proposition concrète de format, vas y :)
L'important c'est qu'il soit facile a générer a partir du format binaire (c'est a dire en un minimum d'opérations).Edited by Éloïs changed this line in version 4 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
312 313 ### Peer card binary format 314 315 | data name | size in bytes | data type | 316 |:-----------------:|---------------|------------------------------------| 317 | peer_card_size | 2 | u16 | 318 | version | 1 | u8 | 319 | endpoints_count | 1 | u8 | 320 | currency_code | 2 | u16 | 321 | node_id | 4 | u32 | 322 | issuer_public_key | 32 | [u8; 32] | 323 | blockstamp | 36 | Blockstamp | 324 | endpoints_datas | calculate* | [(u16, endpoint); endpoints_count] | 325 | signature | 64 | [u8; 64] | 326 327 endpoints_datas := tuples table (endpoint_size, endpoint). -
endpoints_datasest un tableau de tuples, ça veut dire que chaque élément du tableau est un tuple (endpoint_size, endpoint).Ça veut juste dire que chaque endpoint du tableau est précédé d'un champ indiquant sa taille. faut juste que je précise que
endpoint_sizeest de typeu16, je vais le rajouter :) changed this line in version 5 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
319 | endpoints_count | 1 | u8 | 320 | currency_code | 2 | u16 | 321 | node_id | 4 | u32 | 322 | issuer_public_key | 32 | [u8; 32] | 323 | blockstamp | 36 | Blockstamp | 324 | endpoints_datas | calculate* | [(u16, endpoint); endpoints_count] | 325 | signature | 64 | [u8; 64] | 326 327 endpoints_datas := tuples table (endpoint_size, endpoint). 328 329 `endpoint` type is defined above (See "Endpoint format"). 330 331 The document is represented by an array of bytes containing (peer_card_size + 2) bytes. 332 to sign the document it is necessary to calculate the hash sha256 of this bytes array then to sign the hash obtained with the issuer's private key. 333 334 ### Peer card JSON format changed this line in version 5 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
373 374 The WS2P module attempts to establish outcoming connections at the kick-start of the node and then every 10 minutes. 375 At each attempt, all known endpoints are contacted until the outcoming quota is reached. 376 If the outcoming quota is already reached at the beginning of an attempt, the least priority connection is removed in order to keep the network dynamic and scalable. 377 378 The WS2P module does not attempt to connect randomly to any node among those of which it knows a WS2P endpoint, 379 it classifies them according to the following criteria : 380 381 ### 1st criterion: the network layer 382 383 If the node is configured to use an X network layer, then all nodes that accept a connection through this X network layer will have priority. 384 Currently, only the TOR network layer is implemented. 385 386 _Note: the first criterion takes precedence over the second one._ 387 388 ### 2nd criterion: priority score - rfc/0006_ws2p_v2.md 0 → 100644
422 | chunk_hash* | 32 | [u8; 32] | 423 424 challenge := random hash generated by the sending node of the CONNECT message, the receiving node will then have to sign this challenge and then send this signature in its ACK message to prove that it has the corresponding private key to the public key it indicates. 425 426 api_features := This is exactly the same type as the field of the same name in the endpoints. But private WS2P nodes do not declare endpoints, so they must be able to indicate in the CONNECT message which features they support. Public WS2P nodes also fill this field, so any changes in the configuration of a public node will be applied on the 1st new connection. (If this was not the case, we would have to wait for the update of the peer record). 427 428 flags_queries := See "WS2PFlags type definition" below. 429 430 peer_card := This field is optional, if it's not present it must be replaced by 2 bytes filled with zeros. Why two bytes ? Because the first field of any peer card, `peer_card_size`, is 2 bytes long. 431 432 _*Fields `chunk_id` and `chunk_hash` are present only if flag `ASK_SYNC_CHUNK` is present in `flags_queries`._ 433 434 chunk_id := Last block number of the chunk. 435 chunk_hash := Last block hash of the chunk. 436 437 #### WS2PFlags type definition -
je n'ai pas rédigé de partie sur les procédures anti-spam car je ne sais pas comment ©@c-geek gère ça coté duniter-ts et ne souhaite pas y toucher. Mais le système anti-spam est en amont, avant l'évaluation de ce flag. Coté duniter-rust il y aura bien des procédures anti-spam, mais comme ce ne sera pas commun ça na pas sa place dans la RFC.
Et puis ces flags ne forcent pas la connexion, il évitent de subir la limite des quotas de connexion, c'est tout. De plus, quelque soit les flags présent, il faut en tout les cas passer par la négociation CONNECT->ACK->OK dans tout les cas, et en cas de surcharge d'un noeud la négociation échouera a cause du timeout.
RES_SYNC_CHUNK permet d'accélérer la synchronisation d'un noeud qui aurai activé WS2P public, le réseau peut alors spontanément le contacter pour lui envoyer des chunk, c'est ce qu'indique le flag RES_SYNC_CHUNK. Cela permet au noued en cours de sync de priéoriser les connexions entrantes de ce type, vis a vis des connexions "normales". En fait le noeud sera en WS2P classique tout au long de la sync.
changed this line in version 33 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
462 | data name | size in bytes | data type | 463 |:-------------:|---------------|-----------------| 464 | flags_size | 1 | u8 | 465 | flags | flags_size | WS2PSecretFlags | 466 | member_proof | 64 | [u8; 64] | 467 | member_pubkey | 32 | [u8; 32] | 468 469 #### WS2PSecretFlags type definition 470 471 | bit | flag | 472 |:---------:|-----------------| 473 | 0000_0001 | LOW_FLOW_DEMAND | 474 | 0000_0010 | MEMBER_PUBKEY | 475 | 0000_0100 | MEMBER_PROOF | 476 477 LOW_FLOW_DEMAND := The sender node of this message indicates that it's behind a low speed connection and therefore care must be taken to transmit low volumes of data to it. -
Ce sera a déterminer a l'usage, je prévois la feature car ça me semble être un besoin. Tout ce que fera le code dans un premier temps c'est de faire attention a n'envoyer que des infos indispensables et pas déjà envoyés, ce qui demande un cache et du pré-traitement, voila pourquoi on ne le fait pas pour les connexions normales.
changed this line in version 5 of the diff
- rfc/0006_ws2p_v2.md 0 → 100644
251 252 S := This feature indicates that the endpoint should be contacted with an SSL/TLS overlay (HTTPS or WSS). 253 254 TOR := This feature indicates that the endpoint must be contacted via the tor network (hidden service). 255 256 #### api_features 257 258 The interpretation of this field depends on the API because it represents API-specific features. Here is the interpretation for the WS2P API : 259 260 WS2PFeatures type definition : 261 262 | bit | feature | 263 |:---------:|-----------| 264 | 0000_0001 | DEFLATE | 265 | 0000_0010 | LOW | 266 | 0000_0100 | RBF | changed this line in version 4 of the diff
