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
<tdalign="left" valign="top"><pclass="table">Specify magnet link. <ahref="http://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
1477
+
<tdalign="left" valign="top"><pclass="table">Specify magnet link. <ahref="https://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
<divclass="paragraph"><p>For TTH roots, b is 192 and a reasonable value for h is 24, giving a maximum k = 8 which means that m = 8 * n / ln 2 ≈ 11.5 * n. The required bandwidth then becomes 11.5 * n / 8 bytes, so approximately 1.44 bytes per file in the users share. For 20000 files, m should then be 230016 (taking into account the modulo 64 requirement), giving a p = 0.004, in other words ~99.6% of all searches that don’t match a users share would not be sent, saving valuable upload bandwidth for the hub. The client calculates i valid positions, if x is an array of bytes containing the hash of the file, on a little-endian machine, by doing pos = x[0+i*h/8] | (x[1+i*h/8] << 8) | (x[2+i*h/8] << 16) for i = [0;k). This is of course a special case where h % 8 = 0, the actual algorithm has to take into consideration values for h where the integer crosses byte boundaries.</p></div>
1621
-
<divclass="paragraph"><p>For test vectors, see the <ahref="http://www.adcportal.com/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
1639
+
<divclass="paragraph"><p>For test vectors, see the <ahref="https://adc.sourceforge.io/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
<divclass="paragraph"><p>Clients do not signal each atomic user update of the share using the SF flag. Instead, they tend to send a cumulative result of multiple updates in a timely fashion. However, an unambiguous summary of the number of hash additions and removals may result in a lack of an update signal. Therefore, hubs are recommended to look for and process INFs containing the SS flag as well, since an incoming SS flag (especially when not accompanied by an SF) may also indicate an update in the hashes, one that occurs without a change in the total number of files shared.</p></div>
1645
+
<divclass="paragraph"><p>Clients shall strive to signal multiple share updates in an unambiguous manner, thus enabling hubs to request the most accurate and up-to-date version of the client’s bloom filter.</p></div>
<divclass="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <spanclass="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br/>[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <ahref="http://www.brynosaurus.com/pub/net/p2pnat/">http://www.brynosaurus.com/pub/net/p2pnat/</a>]<br/></span>.</p></div>
1650
+
<divclass="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <spanclass="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br/>[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <ahref="https://bford.info/pub/net/p2pnat/">https://bford.info/pub/net/p2pnat/</a>]<br/></span>.</p></div>
1628
1651
<divclass="paragraph"><p>If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn’t support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF’s SU field.</p></div>
1629
1652
<divclass="paragraph"><p>Do note that the hub must forward I4 or I6 for respective clients' INF.</p></div>
1630
1653
<divclass="paragraph"><p>An endpoint is the tuple of IP and port. The "private endpoint port" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint port" as specified in <spanclass="footnoteref"><br/><ahref="#_footnote_Peer-to-Peer Communication Across Network Address Translators">[Peer-to-Peer Communication Across Network Address Translators]</a><br/></span> is not supported.</p></div>
<divclass="paragraph"><p>This extension’s purpose is to notify the hub which user locale the client is using as well as the default locale for the hub. This allows hubs to customize text sent to clients, depending on language, left-to-right or right-to-left and more. If the hub does not directly support the client’s locale, it should attempt to fall back to the same language group (e.g. hub supports en-US but not en-AU, so falls back to en-US), and if this is not available, then fall back to the hub’s own locale.</p></div>
1769
-
<divclass="paragraph"><p><ahref="http://tools.ietf.org/html/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
1792
+
<divclass="paragraph"><p><ahref="https://www.rfc-editor.org/info/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
<h3id="_type_typing_notification">4.18. TYPE - Typing notification</h3>
1962
-
<divclass="paragraph"><p>This extension adds a typing similar to Jabber’s <ahref="http://www.xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
1985
+
<divclass="paragraph"><p>This extension adds a typing similar to Jabber’s <ahref="https://xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
1963
1986
<divclass="paragraph"><p>Signal TYPE in SUP and the INF’s SU field.</p></div>
<h3id="_ccpm_client_to_client_private_messages">4.33. CCPM - Client to client private messages</h3>
2712
+
<divclass="paragraph"><p>This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses the field "PM" in the (C-type) INF to signal that the connection should be used for private messages. Implementations supporting this extension must signal "CCPM" in the SU field of their hub-targeted INF.</p></div>
2713
+
<divclass="paragraph"><p>Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.</p></div>
2714
+
<divclass="paragraph"><p>Implementations are strongly discouraged but may choose to allow private messages in unencrypted connections.</p></div>
2715
+
<divclass="paragraph"><p>Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).</p></div>
2716
+
<divclass="paragraph"><p>Absence of the "PM" field from the (C-type) INF shall cause a disconnect of the connection (with an appropriate STA).</p></div>
2717
+
<divclass="paragraph"><p>Implementations may decide what to do when the hub connection is lost during a private message connection.</p></div>
2718
+
<divclass="paragraph"><p>Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Further actions beyond that are up to implementations.</p></div>
2719
+
<divclass="paragraph"><p>The same port may, but needn’t be, reused for a file transfer connection and a private message connection. Concurrent connections may be rendered unfeasible with extensions such as NATT.</p></div>
2720
+
<divclass="paragraph"><p>The "PM" field of the MSG command should not be used in C-C private messages.</p></div>
<tdalign="left" valign="top"><pclass="table">Field in the CINF to denote that the connection should be used for private messages. The field’s value should be <em>1</em>.</p></td>
0 commit comments