Re: [cf-dev] RE : RE : Clean-up mechanism for blockwise transfer is remo

["Kovatsch Matthias" <kovatsch@xxxxxxxxxxx>]

Hi there

Since we still have to decide on the version/branch management, I pushed a new (temporary) branch that contains a fix, but needs more testing:

https://github.com/eclipse/californium.core/tree/blockwise-no-rst

Gilles, could you check if this resolves your issue?

Californium was resetting blockwise transfers and canceling the request when receiving out-of-order blocks. As this could happen through convoluted blockwise transfers, I relaxed this policy. I still need to test strange remote behavior, that is, what happens when only wrong blocks are received and if we now need to extend the clean-up mechanism.

Ciao
Matthias


> -----Original Message-----
> From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Kovatsch Matthias
> Sent: Freitag, 25. Dezember 2015 21:45
> To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> Subject: Re: [cf-dev] RE : RE : Clean-up mechanism for blockwise transfer is
> removing observe state
> 
> > Observe is working OK over long period of time if there is no block2
> > option involves in the observe response.
> 
> I was explicitly testing with the obs-large resource, which involves Block2
> notifications. I redid some tests using the cf-client, which is running
> successfully with Block2 notifications for several hours now.
> 
> > I have extracted more logs but I still cannot explain what is going on.
> 
> At the Connector level it is hard to see what is going on. Using the
> MessageTracer interceptor might help.
> 
> However, I had the suspicion that it is related to a race condition when new
> notifications interfere with an ongoing blockwise transfer. A request
> cancellation is triggered, when a wrong block number is received. This could
> happen when a blockwise notification arrives during a blockwise transfer and
> a new block is requested just before an old block arrives.
> 
> 11 WARNING [BlockwiseLayer]: Ongoing blockwise transfer reseted at
> num=2 by new notification: CON-2.05   MID=51132, Token=33bae1,
> OptionSet={"Observe":1399451, "Content-Format":"text/plai", "Max-Age":5,
> "Block2":"(szx=2/64, m=true, num=0)"}, "------------------------".. 64 bytes -
> (org.eclipse.californium.core.network.stack.BlockwiseLayer.java:350)
> receiveResponse() in thead Thread-1 at (2015-12-25 14:46:47)
> 11 WARNING [Matcher]: Possible MID reuse before lifetime end: 33bae1
> expected MID 32965 but received 32964 -
> (org.eclipse.californium.core.network.Matcher.java:347) receiveResponse()
> in tread Thread-1 at (2015-12-25 14:46:47)
> 11 WARNING [BlockwiseLayer]: Wrong block number. Expected 1 but
> received 2. Reject response; exchange has failed. -
> (org.eclipse.californium.core.network.stack.BlockwiseLayer.java:458)
> reeiveResponse() in thread Thread-1 at (2015-12-25 14:46:47)
> 
> In general, such situations should be avoided by choosing a prober
> notification period, so that all blocks can actually be transmitted. Yet I will
> improve the BlockwiseLayer, so that such overlaps are temporarily possible.
> 
> Ciao
> Matthias
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev