summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2021-12-24 12:28:07 +0100
committerMartin Schanzenbach <schanzen@gnunet.org>2021-12-24 12:28:07 +0100
commit9346b9b61174f9b61e86cc5db2cad1e18bf86ffc (patch)
tree27c8890168a9c623be4c17cf5df63878c78b751a
parentf938cdfbd3be80aba346a462e8a0ce6b3f244035 (diff)
downloadlsd0004-9346b9b61174f9b61e86cc5db2cad1e18bf86ffc.tar.gz
lsd0004-9346b9b61174f9b61e86cc5db2cad1e18bf86ffc.zip
some message processing with FIXMEs
-rw-r--r--draft-schanzen-r5n.xml419
1 files changed, 292 insertions, 127 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 955624c..9e0d9e4 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -586,6 +586,8 @@ END
586 </section> 586 </section>
587 <section anchor="p2p_put" numbered="true" toc="default"> 587 <section anchor="p2p_put" numbered="true" toc="default">
588 <name>PUT message</name> 588 <name>PUT message</name>
589 <section anchor="p2p_put_wire">
590 <name>Wire Format</name>
589 <figure anchor="figure_putmsg"> 591 <figure anchor="figure_putmsg">
590 <artwork name="" type="" align="left" alt=""><![CDATA[ 592 <artwork name="" type="" align="left" alt=""><![CDATA[
5910 8 16 24 32 40 48 56 5930 8 16 24 32 40 48 56
@@ -671,12 +673,66 @@ END
671 by the BTYPE field. 673 by the BTYPE field.
672 </dd> 674 </dd>
673 </dl> 675 </dl>
674 676 </section>
677 <section anchor="p2p_put_processing">
678 <name>Processing</name>
679 <t>
680 Upon receiving a PUT message from a connected peer. An implementation
681 MUST process it step by step as follows:
682 </t>
683 <ol>
684 <li>
685 The EXPIRATION field is evaluated. If the message is expired,
686 it MUST be discarded.
687 </li>
688 <li>
689 If the BTYPE is not supported by the implementation, no validation
690 of the block payload is performed and processing continues at (4).
691 Else, the block MUST be validated as defined in (3).
692 </li>
693 <li>
694 The block key is extracted from BLOCK. If the block key
695 does not match KEY or cannot be extracted because the BLOCK
696 is malformed, the message MUST be discarded.
697 The block is evaluated. TODO FIXME: In the code, we do not really
698 do this. We should review.
699 </li>
700 <li>
701 The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
702 implementation MAY log an error, but MUST continue.
703 </li>
704 <li>
705 If the "Record Route" flag is set in OPTIONS, add the local peer ID
706 to PUTPATH. FIXME: Should should come way later (?)
707 </li>
708 <li>
709 If the KEY of this PUT message is in the list of pending queries,
710 return the message through the API. FIXME: Is this a conversion to
711 a RESULT??
712 </li>
713 <li>
714 If the local peer is the closest peer (AM-CLOSEST-PEER) or the
715 "Demultiplex Everywhere" options flag ist set, the message MUST
716 be stored locally in the block storage.
717 </li>
718 <li>
719 Given the value in REPL_LVL, the number of peers to forward to
720 MUST be calculated (NUM-FORWARD-PEERS). If there is at least one
721 peer to forward to, the implementation SHOULD select up to this
722 number of peers to forward the message to. The implementation MAY
723 forward to fewer or no peers in order to handle resource constraints
724 such as bandwidth.
725 The message BLOOMFILTER MUST be updated with the local peer ID.
726 </li>
727 </ol>
728 </section>
675 </section> 729 </section>
676 <section anchor="p2p_get" numbered="true" toc="default"> 730 <section anchor="p2p_get" numbered="true" toc="default">
677 <name>GET message</name> 731 <name>GET Message</name>
678 <figure anchor="figure_getmsg"> 732 <section anchor="p2p_get_wire">
679 <artwork name="" type="" align="left" alt=""><![CDATA[ 733 <name>Wire Format</name>
734 <figure anchor="figure_getmsg">
735 <artwork name="" type="" align="left" alt=""><![CDATA[
6800 8 16 24 32 40 48 56 7360 8 16 24 32 40 48 56
681+-----+-----+-----+-----+-----+-----+-----+-----+ 737+-----+-----+-----+-----+-----+-----+-----+-----+
682| MSIZE | MTYPE | BTYPE | 738| MSIZE | MTYPE | BTYPE |
@@ -696,70 +752,123 @@ END
696/ BF_RESULT (variable length) / 752/ BF_RESULT (variable length) /
697+-----+-----+-----+-----+-----+-----+-----+-----+ 753+-----+-----+-----+-----+-----+-----+-----+-----+
698 ]]></artwork> 754 ]]></artwork>
699 </figure> 755 </figure>
700 <t>where:</t> 756 <t>where:</t>
701 <dl> 757 <dl>
702 <dt>MSIZE</dt> 758 <dt>MSIZE</dt>
703 <dd> 759 <dd>
704 denotes the size of this message in network byte order. 760 denotes the size of this message in network byte order.
705 </dd> 761 </dd>
706 <dt>MTYPE</dt> 762 <dt>MTYPE</dt>
707 <dd> 763 <dd>
708 is the 16-bit message type. This type can be one of the DHT message 764 is the 16-bit message type. This type can be one of the DHT message
709 types but for put messages it must be set to 765 types but for put messages it must be set to
710 the value 147 in network byte order. 766 the value 147 in network byte order.
711 </dd> 767 </dd>
712 <dt>BTYPE</dt> 768 <dt>BTYPE</dt>
713 <dd> 769 <dd>
714 is a 32-bit block type field. The block type indicates the content 770 is a 32-bit block type field. The block type indicates the content
715 type of the payload. In network byte order. 771 type of the payload. In network byte order.
716 </dd> 772 </dd>
717 <dt>OPTIONS</dt> 773 <dt>OPTIONS</dt>
718 <dd> 774 <dd>
719 is a 16-bit options field (see below). 775 is a 16-bit options field (see below).
720 </dd> 776 </dd>
721 <dt>HOPCOUNT</dt> 777 <dt>HOPCOUNT</dt>
722 <dd> 778 <dd>
723 is a 16-bit number indicating how many hops this message has 779 is a 16-bit number indicating how many hops this message has
724 traversed to far. In network byte order. 780 traversed to far. In network byte order.
725 </dd> 781 </dd>
726 <dt>REPL_LVL</dt> 782 <dt>REPL_LVL</dt>
727 <dd> 783 <dd>
728 is a 16-bit number indicating the desired replication level of 784 is a 16-bit number indicating the desired replication level of
729 the data. In network byte order. 785 the data. In network byte order.
730 </dd> 786 </dd>
731 <dt>XQ_SIZE</dt> 787 <dt>XQ_SIZE</dt>
732 <dd> 788 <dd>
733 is a 32-bit number indicating the length of the optional 789 is a 32-bit number indicating the length of the optional
734 extended query XQUERY. In network byte order. 790 extended query XQUERY. In network byte order.
735 </dd> 791 </dd>
736 <dt>BLOOMFILTER</dt> 792 <dt>BLOOMFILTER</dt>
737 <dd> 793 <dd>
738 A bloomfilter (for peer identities) to stop circular routes. 794 A bloomfilter (for peer identities) to stop circular routes.
739 </dd> 795 </dd>
740 <dt>KEY</dt> 796 <dt>KEY</dt>
741 <dd> 797 <dd>
742 The key under which the PUT request wants to store content 798 The key under which the PUT request wants to store content
743 under. 799 under.
744 </dd> 800 </dd>
745 <dt>XQUERY</dt> 801 <dt>XQUERY</dt>
746 <dd> 802 <dd>
747 the variable-length extended query. Optional. 803 the variable-length extended query. Optional.
748 </dd> 804 </dd>
749 <dt>BF_MUTATOR</dt> 805 <dt>BF_MUTATOR</dt>
750 <dd> 806 <dd>
751 The 32-bit bloomfilter mutator for the result bloomfilter. 807 The 32-bit bloomfilter mutator for the result bloomfilter.
752 </dd> 808 </dd>
753 <dt>RESULT_BF</dt> 809 <dt>RESULT_BF</dt>
754 <dd> 810 <dd>
755 the variable-length result bloomfilter. 811 the variable-length result bloomfilter.
756 </dd> 812 </dd>
757 </dl> 813 </dl>
814 </section>
815 <section anchor="p2p_get_processing">
816 <name>Processing</name>
817 <t>
818 Upon receiving a GET message from a connected peer. An implementation
819 MUST process it step by step as follows:
820 </t>
821 <ol>
822 <li>
823 The KEY and XQUERY is validated against the requested BTYPE.
824 If the BTYPE is not supported, or if the block key
825 does not match the BTYPE or if the XQUERY is malformed,
826 the message MUST be discarded.
827 </li>
828 <li>
829 The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
830 implementation MAY log an error, but MUST continue.
831 </li>
832 <li>
833 <t>
834 If the local peer is the closest peer (AM-CLOSEST-PEER) or the
835 "Demultiplex Everywhere" options flag is set, a reply MUST be
836 produced:
837 </t>
838 <ol>
839 <li>
840 If OPTIONS indicate a "Find Peer" request, FIXME the peer selection
841 foo from buckets that probably needs fixing. Take into account
842 REPLY_BF
843 </li>
844 <li>
845 Else, if there is a BLOCK in the local Block Storage which is
846 not already in the RESULT_BF, a RESULT message MUST be sent.
847 FIXME link to how the result is sent?
848 </li>
849 </ol>
850 </li>
851 <li>
852 FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST??
853 </li>
854 <li>
855 Given the value in REPL_LVL, the number of peers to forward to
856 MUST be calculated (NUM-FORWARD-PEERS). If there is at least one
857 peer to forward to, the implementation SHOULD select up to this
858 number of peers to forward the message to. The implementation MAY
859 forward to fewer or no peers in order to handle resource constraints
860 such as bandwidth.
861 The message BLOOMFILTER MUST be updated with the local peer ID.
862 </li>
863 </ol>
864 </section>
758 </section> 865 </section>
759 <section anchor="p2p_result" numbered="true" toc="default"> 866 <section anchor="p2p_result" numbered="true" toc="default">
760 <name>RESULT message</name> 867 <name>RESULT message</name>
761 <figure anchor="figure_resmsg"> 868 <section anchor="p2p_result_wire">
762 <artwork name="" type="" align="left" alt=""><![CDATA[ 869 <name>Wire Format</name>
870 <figure anchor="figure_resmsg">
871 <artwork name="" type="" align="left" alt=""><![CDATA[
7630 8 16 24 32 40 48 56 8720 8 16 24 32 40 48 56
764+-----+-----+-----+-----+-----+-----+-----+-----+ 873+-----+-----+-----+-----+-----+-----+-----+-----+
765| MSIZE | MTYPE | BTYPE | 874| MSIZE | MTYPE | BTYPE |
@@ -781,75 +890,131 @@ END
781/ (variable length) / 890/ (variable length) /
782+-----+-----+-----+-----+-----+-----+-----+-----+ 891+-----+-----+-----+-----+-----+-----+-----+-----+
783 ]]></artwork> 892 ]]></artwork>
784 </figure> 893 </figure>
785 <t>where:</t> 894 <t>where:</t>
786 <dl> 895 <dl>
787 <dt>MSIZE</dt> 896 <dt>MSIZE</dt>
788 <dd> 897 <dd>
789 denotes the size of this message in network byte order. 898 denotes the size of this message in network byte order.
790 </dd> 899 </dd>
791 <dt>MTYPE</dt> 900 <dt>MTYPE</dt>
792 <dd> 901 <dd>
793 is the 16-bit message type. This type can be one of the DHT message 902 is the 16-bit message type. This type can be one of the DHT message
794 types but for put messages it must be set to 903 types but for put messages it must be set to
795 the value 148 in network byte order. 904 the value 148 in network byte order.
796 </dd> 905 </dd>
797 <dt>OPTIONS</dt> 906 <dt>OPTIONS</dt>
798 <dd> 907 <dd>
799 is a 16-bit options field (see below). 908 is a 16-bit options field (see below).
800 </dd> 909 </dd>
801 <dt>BTYPE</dt> 910 <dt>BTYPE</dt>
802 <dd> 911 <dd>
803 is a 32-bit block type field. The block type indicates the content 912 is a 32-bit block type field. The block type indicates the content
804 type of the payload. In network byte order. 913 type of the payload. In network byte order.
805 </dd> 914 </dd>
806 <dt>PUTPATH_L</dt> 915 <dt>PUTPATH_L</dt>
807 <dd> 916 <dd>
808 is a 16-bit number indicating the length of the PUT path recorded 917 is a 16-bit number indicating the length of the PUT path recorded
809 in PUTPATH. As PUTPATH is optiona, this value may be zero. 918 in PUTPATH. As PUTPATH is optiona, this value may be zero.
810 In network byte order. 919 In network byte order.
811 </dd> 920 </dd>
812 <dt>GET_PATH_LEN</dt> 921 <dt>GET_PATH_LEN</dt>
813 <dd> 922 <dd>
814 is a 16-bit number indicating the length of the GET path recorded 923 is a 16-bit number indicating the length of the GET path recorded
815 in GETPATH. As PUTPATH is optiona, this value may be zero. 924 in GETPATH. As PUTPATH is optiona, this value may be zero.
816 In network byte order. 925 In network byte order.
817 </dd> 926 </dd>
818 <dt>EXPIRATION</dt> 927 <dt>EXPIRATION</dt>
819 <dd> 928 <dd>
820 denotes the absolute 64-bit expiration date of the content. 929 denotes the absolute 64-bit expiration date of the content.
821 In microseconds since midnight (0 hour), January 1, 1970 in network 930 In microseconds since midnight (0 hour), January 1, 1970 in network
822 byte order. 931 byte order.
823 </dd> 932 </dd>
824 <dt>KEY</dt> 933 <dt>KEY</dt>
825 <dd> 934 <dd>
826 The key under which the PUT request wants to store content 935 The key under which the PUT request wants to store content
827 under. 936 under.
828 </dd> 937 </dd>
829 <dt>PUTPATH</dt> 938 <dt>PUTPATH</dt>
830 <dd> 939 <dd>
831 the variable-length PUT path. 940 the variable-length PUT path.
832 The path consists of a list of PATH_LEN peer IDs. 941 The path consists of a list of PATH_LEN peer IDs.
833 </dd> 942 </dd>
834 <dt>GETPATH</dt> 943 <dt>GETPATH</dt>
835 <dd> 944 <dd>
836 the variable-length PUT path. 945 the variable-length PUT path.
837 The path consists of a list of PATH_LEN peer IDs. 946 The path consists of a list of PATH_LEN peer IDs.
838 </dd> 947 </dd>
839 <dt>BLOCK</dt> 948 <dt>BLOCK</dt>
840 <dd> 949 <dd>
841 the variable-length resource record data payload. 950 the variable-length resource record data payload.
842 The contents are defined by the respective type of the resource record. 951 The contents are defined by the respective type of the resource record.
843 </dd> 952 </dd>
844 </dl> 953 </dl>
954 </section>
955 <section anchor="p2p_result_processing">
956 <name>Processing</name>
957 <t>
958 Upon receiving a RESULT message from a connected peer. An implementation
959 MUST process it step by step as follows:
960 </t>
961 <ol>
962 <li>
963 The EXPIRATION field is evaluated. If the message is expired,
964 it MUST be discarded.
965 </li>
966 <li>
967 If the MTYPE of the message indicates a HELLO block, the
968 payload MUST be considered for the local routing table.
969 FIXME: Considered how?
970 </li>
971 <li>
972 If the sender peer (FIXME which peer?) is already found in the
973 GETPATH, the path MUST be truncated.
974 </li>
975 <li>
976 FIXME: No validation??
977 </li>
978 <li>
979 If the KEY of this PUT message is in the list of pending queries,
980 return the message through the API.
981 </li>
982 <li>
983 The implementation MAY cache RESULT messages.
984 </li>
985 <li>
986 If no requests for this KEY or BTYPE are known, result processing
987 is completed.
988 </li>
989 <li>
990 If the request is of type "Find Peer" and the message BTYPE is
991 of type HELLO the block key is extracted from BLOCK, and if the
992 block key does not match KEY or cannot be extracted because
993 the BLOCK is malformed, the message MUST be discarded.
994 Otherwise, the block is evaluated against the message KEY.
995 FIXME: If OK_MORE or OK_LAST the RESULT is routed. One (!) peer is
996 selected from the connected peers (!). If none is found the message
997 is discarded.
998 </li>
999 </ol>
1000 </section>
845 </section> 1001 </section>
846 </section> 1002 </section>
847 <section> 1003 <section>
848 <name>Bootstrapping</name> 1004 <name>Bootstrapping</name>
849 <t> 1005 <t>
1006 It is assumed that the peer is already connected to at least
1007 one other peer.
1008 First, those initial peers are sorted into their respective buckets.
1009 </t>
1010 <t>
850 In order to find the closest peers in the network to itself, an 1011 In order to find the closest peers in the network to itself, an
851 implementation MUST periodically send HELLO GET queries for its own 1012 implementation MUST now periodically send HELLO GET queries for its own
852 peer ID. 1013 peer ID.
1014 Both the "record route" and "find peer" message options are set in the
1015 GET queries in order to learn peers and network topology from the
1016 message route and in order to receive approximate replies to the
1017 query key (the peer ID).
853 </t> 1018 </t>
854 <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t> 1019 <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t>
855 <t> 1020 <t>