I think implementation errors might happen when fine-grained locks will be introduced:
Nodes A and B MAY support having two transactions going on at the same time, one in each direction. Similarly, a node MAY support concurrent 6P Transactions from different neighbors. In this case, the cells involved in an ongoing 6P Transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and R. In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors it MUST reply with a 6P Response with return code NORES. In case the requested cells are locked, it MUST reply to that request with a 6P Response with return code BUSY. The node receiving BUSY or an NORES MAY implement a retry mechanism, defined by the SF. Le mar. 20 juin 2017 à 08:24, Xavi Vilajosana Guillen <[email protected]> a écrit : > Hi Remy, > > in my way of seeing this, and assuming 6N1 goes first in the transaction, > 6N2 will receive the BUSY as the resource is locked by 6N1, 6N1 will be > able to finalize as it started the transaction before 6N2 and locked the > resources. Note that the request message lock the resources. > > I want to hear other view as well about this. > > regards, > X > > 2017-06-19 18:14 GMT+02:00 Remy Leone <[email protected]>: > >> If it is a concurrent situation it's also likely that 6N1 will receive >> the BUSY. There is no explicit locking. >> >> Le lun. 19 juin 2017 à 18:13, Xavi Vilajosana Guillen < >> [email protected]> a écrit : >> > Hi Remy, >>> >>> this is a concurrent situation so both should happen almost at the same >>> time. The return code to 6N2 is BUSY. >>> >>> regards, >>> X >>> >>> 2017-06-19 16:37 GMT+02:00 Remy Leone <[email protected]>: >>> >>>> Hello, >>>> >>>> I got a question about 6P04: >>>> >>>> obj: Check that concurrent transaction cannot request for the same >>>> cells in the schedule according to draft-ietf-6tisch-6top-protocol-05 >>>> cfg: star >>>> ref: IEEE802.15.4-2015, draft-ietf-6tisch-6top-protocol-05 >>>> pre: >>>> - The DAGroot sends EBs periodically, with a fast rate (equal to 10 >>>> sec, according to IEEE802.15.4std), so that the 6N does not need to send >>>> KAs for keeping synchronization. >>>> - All EB packets are sent on a single frequency. >>>> - Power on DAGroot. >>>> - Wait until all 6N join the DAGroot >>>> seq: >>>> - s: >>>> - The 6N1 sends a 6P ADD request to the DAGroot for 2 slots. >>>> - The candidate list is {4,5}. >>>> - s: >>>> - The 6N2 sends a 6P ADD request to the DAGroot for 2 slots. >>>> - The candidate list is {4,5}. >>>> - c: >>>> - Check that the returned code for the operation is BUSY. >>>> >>>> Should we add more details about the timing? Because the check step >>>> seems very imprecise. Is it the 6N2 that get the busy return code? The 6N1? >>>> Do we have answers each time a request is sent? >>>> >>>> Best regards >>>> >>>> Rémy >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> >>> -- >>> Dr. Xavier Vilajosana >>> Wireless Networks Lab >>> >>> *Internet Interdisciplinary Institute (IN3)Professor* >>> (+34) 646 633 681 <+34%20646%2063%2036%2081> >>> [email protected] <[email protected]> >>> http://xvilajosana.org >>> http://wine.rdi.uoc.edu >>> Parc Mediterrani de la Tecnologia >>> Av Carl Friedrich Gauss 5, B3 Building >>> 08860 Castelldefels (Barcelona). Catalonia. Spain >>> [image: Universitat Oberta de Catalunya] >>> >>> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > [email protected] <[email protected]> > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
