diff options
Diffstat (limited to 'draft-summermatter-set-union.xml')
-rw-r--r-- | draft-summermatter-set-union.xml | 47 |
1 files changed, 35 insertions, 12 deletions
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml index c2e154a..c0a8d52 100644 --- a/draft-summermatter-set-union.xml +++ b/draft-summermatter-set-union.xml | |||
@@ -1648,6 +1648,10 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 | | |||
1648 | <dd> | 1648 | <dd> |
1649 | is SETU_P2P_DONE as registered in <xref target="gana" format="title" /> in network byte order. | 1649 | is SETU_P2P_DONE as registered in <xref target="gana" format="title" /> in network byte order. |
1650 | </dd> | 1650 | </dd> |
1651 | <dt>FINAL CHECKSUM</dt> | ||
1652 | <dd> | ||
1653 | a SHA-512 bit hash of the full set after synchronization. This should ensure that the sets are identical in the end! | ||
1654 | </dd> | ||
1651 | </dl> | 1655 | </dl> |
1652 | </section> | 1656 | </section> |
1653 | </section> | 1657 | </section> |
@@ -1672,8 +1676,10 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 | | |||
1672 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1676 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1673 | 0 8 16 24 32 40 48 56 | 1677 | 0 8 16 24 32 40 48 56 |
1674 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1678 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
1675 | | MSG SIZE | MSG TYPE | | 1679 | | MSG SIZE | MSG TYPE | FINAL CHECKSUM |
1676 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 1680 | +-----+-----+-----+-----+ |
1681 | / / | ||
1682 | / / | ||
1677 | ]]></artwork> | 1683 | ]]></artwork> |
1678 | </figure> | 1684 | </figure> |
1679 | <t>where:</t> | 1685 | <t>where:</t> |
@@ -1686,6 +1692,10 @@ hashSum | 0x0101 | 0x5151 | 0x5050 | 0x0000 | | |||
1686 | <dd> | 1692 | <dd> |
1687 | the type of SETU_P2P_FULL_DONE as registered in <xref target="gana" format="title" /> in network byte order. | 1693 | the type of SETU_P2P_FULL_DONE as registered in <xref target="gana" format="title" /> in network byte order. |
1688 | </dd> | 1694 | </dd> |
1695 | <dt> FINAL CHECKSUM</dt> | ||
1696 | <dd> | ||
1697 | a SHA-512 bit hash of the full set after synchronization. This should ensure that the sets are identical in the end! | ||
1698 | </dd> | ||
1689 | </dl> | 1699 | </dl> |
1690 | </section> | 1700 | </section> |
1691 | </section> | 1701 | </section> |
@@ -2853,9 +2863,12 @@ END FUNCTION | |||
2853 | <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE, | 2863 | <!-- FIXME: I don't see how the next sentence makes sense. If we got a FULL_DONE, |
2854 | and we still have differing sets, something is broken and re-doing it hardly | 2864 | and we still have differing sets, something is broken and re-doing it hardly |
2855 | makes sense, right? @Christian im not sure about that it could be that for example | 2865 | makes sense, right? @Christian im not sure about that it could be that for example |
2856 | the set size changes (from application or other sync) while synchronisation is in progress....--> | 2866 | the set size changes (from application or other sync) while synchronisation is in progress.... something went |
2857 | If the sets differ, a resynchronisation is required. The number of possible | 2867 | wrong (HW Failures) Should never occur! Fehlgeschlagen! Final checksum in done/full done sha512--> |
2858 | resynchronisation MUST be limited, to prevent resource exhaustion attacks. | 2868 | |
2869 | If the sets differ (the FINAL CHECKSUM field in the <xref target="messages_full_done" format="title" /> | ||
2870 | does not match to the sha-512 hash in our set), The operation has failed. This is a strong indicator | ||
2871 | that something went horribly wrong (eg. some hardware bug), this should never ever happen! | ||
2859 | </t> | 2872 | </t> |
2860 | </dd> | 2873 | </dd> |
2861 | </dl> | 2874 | </dl> |
@@ -2888,7 +2901,12 @@ END FUNCTION | |||
2888 | all of the other fragments/parts of the IBF first and | 2901 | all of the other fragments/parts of the IBF first and |
2889 | that the parameters are thus consistent apply. @Christian So we would have | 2902 | that the parameters are thus consistent apply. @Christian So we would have |
2890 | to transmit the number of IBF slices that will be transmitted first | 2903 | to transmit the number of IBF slices that will be transmitted first |
2891 | to do this check right? | 2904 | to do this check right? Empfangen in mononer rheienfolge und prüfen das |
2905 | es der letzte war. Sizes immer gleich? | ||
2906 | Grösse plausible check: | ||
2907 | - initiale bzyantine Upper bound verküpfen auf setsize differenz | ||
2908 | - Wiederholt das ding kann sich nur verdoppeln | ||
2909 | - Genau prüffen durch offer/demands | ||
2892 | --> | 2910 | --> |
2893 | </dl> | 2911 | </dl> |
2894 | </section> | 2912 | </section> |
@@ -2900,19 +2918,24 @@ END FUNCTION | |||
2900 | generating and transmitting an unlimited number of IBFs that all do not decode, or | 2918 | generating and transmitting an unlimited number of IBFs that all do not decode, or |
2901 | to generate an IBF constructed to send the peers in an endless loop. | 2919 | to generate an IBF constructed to send the peers in an endless loop. |
2902 | To prevent an endless loop in decoding, loop detection MUST be implemented. | 2920 | To prevent an endless loop in decoding, loop detection MUST be implemented. |
2903 | The simplest solution is to prevent decoding of more than a given number of elements. | 2921 | The first solution is to prevent decoding of more than a given number of elements. |
2904 | <!-- FIXME: this description is awkward. Needs to be discussed. | 2922 | <!-- FIXME: this description is awkward. Needs to be discussed. |
2905 | I think you also do not mean 'hashes' but 'element IDs'. @Christian just omit the details | 2923 | I think you also do not mean 'hashes' but 'element IDs'. @Christian just omit the details |
2906 | i guess anybody can freely decide how to handle loops its just important that e protection is | 2924 | i guess anybody can freely decide how to handle loops its just important that e protection is |
2907 | in place. Right?--> | 2925 | in place. Right? |
2908 | A more robust solution is to implement a algorithm that detects a loop by | 2926 | - Remove salt and save this in the hashmap |
2927 | - vorher gespreichert. | ||
2928 | - Beides machen | ||
2929 | - Nie mehr als MIN(anzahl buckets,total set grössen) | ||
2930 | --> | ||
2931 | A more robust solution is to implement an algorithm that detects a loop by | ||
2909 | analyzing past partially decoded IBFs. This can be achieved | 2932 | analyzing past partially decoded IBFs. This can be achieved |
2910 | by saving the element IDs of all prior partly decoded IBFs hashes in a hashmap and check | 2933 | by saving the element IDs of all prior partly decoded IBFs element IDs in a hashmap and check |
2911 | for every inserted hash, if it is already in the hashmap. | 2934 | for every inserted element ID, if it is already in the hashmap. |
2912 | </t> | 2935 | </t> |
2913 | <t> | 2936 | <t> |
2914 | If the IBF decodes more elements than are plausible, the | 2937 | If the IBF decodes more elements than are plausible, the |
2915 | operation MUST be terminated.Furthermore, if the IBF | 2938 | operation MUST be terminated. Furthermore, if the IBF |
2916 | decoding successfully terminates and fewer elements were | 2939 | decoding successfully terminates and fewer elements were |
2917 | decoded than plausible, the operation MUST also be terminated. | 2940 | decoded than plausible, the operation MUST also be terminated. |
2918 | The upper thresholds for decoded elements from the IBF is the | 2941 | The upper thresholds for decoded elements from the IBF is the |