-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: > inline > > On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin <[email protected]> wrote: > More questions, comments and nits: > > - A.9. In section 5.1.2, 5th paragraph: "As an example of the second strategy, > if node D receives a message from node C with transaction X and via list (A, > B), > it could store (X, C) in its state database and forward the message with the > via > list unchanged. When D receives the response, it consults its state database > for transaction id X, determines that the request came from C, and forwards > the > response to C." > > If I understand correctly this whole paragraph, when a message is forwarded it > keeps the same transaction_id, because if the response received by D was > using a > different transaction_id, say Y, it could not retrieve (X, C) from the state > database. Is this analysis correct? > >> A message should always keep the same transaction ID. The paragraph >> is really just trying to point out that you can keep a map of tid -> >> return node for your routing state.
In fact this is implied by the fact that the Signature in the SecurityBlock covers transaction_id. Sorry for that. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk05zWUACgkQ9RoMZyVa61eYjwCdFlFuviv2Sd0S0HYyb+rQjtTn d7EAn3M4s+2BrQZ4UYPBewXL3h8Yby54 =eGya -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
