Hello Tengfei But if the ack is sent and not received then the parent does not allocate the cells and the child uses them...
And if a transaction hangs in the middle - say the child dies or is out of reach - then we'd have a deadlock. No, as Xavi said we must plan for parallel transaction and roll back on error and time out. Cheers, Pascal Le 4 mars 2016 ? 14:06, Tengfei Chang <[email protected]<mailto:[email protected]>> a ?crit : Hi Pascal, The parent should allocate cells only when it received the ACK of the response. If no ACK received, no cell will be allocated. This can be handled by state machine, though it doesn't support concurrency. Tengfei On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: One issue with that, Tengfei, is if the 6p response is sent but not received. The client will retry the request for the same need of bandwidth but will get a new set of cells. The parent that allocates cells must correlate them with a request ID (token, sequence, whatever) in case that request is retried so as to respond with the same cells. Take care, Pascal From: 6tisch [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Tengfei Chang Sent: jeudi 3 mars 2016 18:48 To: Prof. Diego Dujovne <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P Hello Diego, For the Token to identify the transaction, personally, if the idea is to identify a request and a response with a token, it can be replaced by implementing a status machine, in which the status is able to identify the status of 6P transaction. Here is a rough example which is able to explain how Status Machine works: Initially the status of 6P can be set as 6P_IDLE. For a mote sending 6p request: 1. after the 6p request is ready to be sent which contains the candidate cell, the status turns to 6P_REQUEST_INIT 2. after the request is sent, the status turns to 6P_REQUEST_WAITING_RESPONSE 3. after received the response from parent, mote sends ACK back and add/delete cell in schedule. The status turns to 6P_IDLE For a mote received 6p request: 1. after receiving the 6p request, the mote turns status to 6P_RECEIVED_REQUEST 2. when cells are selected or no cell is available, set status to 6P_RESPONSE_TOBESENT 3. after sending the response and get the ACK, mote will add/delete cells in schedule and set status back to 6P_IDLE If the mote will not process the next 6P request if the status is correct. Even if there are some issue that the mote stuck at one status, the timeout will reset the status to 6P_IDLE. With this, one byte can be save, though it's not that much. What do you think? Tengfei On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <[email protected]<mailto:[email protected]>> wrote: Dear all, In order to continue the discussion we left unfinished at the Interim meeting in March 26th, I will open a number of threads to take action on several pending issues for the drafts: draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol) draft-dujovne-6tisch-6top-sf0-00 - Regarding the use of a Token to identify transactions on the 6top protocol, there was a proposal on the call to add an 8-bit field to the packet header. Do you agree with this solution? Regards, Diego Dujovne -- DIEGO DUJOVNE Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones Facultad de Ingenier?a UDP www.ingenieria.udp.cl<http://www.ingenieria.udp.cl> (56 2) 676 8125 _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
