JosefWN
commented
2 years ago Ah, ouch. The token for the "overarching" request is set in the exchange when fireRespond is called: https://github.com/shamblett/coap/blob/4.2.1/lib/src/net/coap_exchange.dart#L154
For blockwise this is the last token in the blockwise exchange.
I can test a bit too. Just for reference, server that could be used for testing (can be modified to return blockwise): https://github.com/plgd-dev/go-coap/tree/master/examples/mcast/server
Client:
FutureOr<void> main(final List<String> args) async {
final conf = CoapConfig();
final uri = Uri(
scheme: 'coap',
host: CoapDefinedAddress.allCOAPNodesIPV4,
port: conf.defaultPort,
);
final client = CoapClient(uri, conf);
try {
final req = CoapRequest.newGet()..uriPath = '/oic/res';
await client.send(
req,
onMulticastResponse: CoapMulticastResponseHandler(print),
);
} on Exception catch (e) {
print('CoAP encountered an exception: $e');
}
client.close();
}Maybe the check could simply return true if multicast is being used, like so?
I think this wouldn't work if you have two different multicast requests running concurrently, then there would be no filtering mechanism between responses for the two?
EDIT: I think multicast block1 requests are not supported as per the RFC, which leaves block2 for us to investigate: https://datatracker.ietf.org/doc/html/rfc7959#section-2.8
Other uses of the Block options [than block2] in conjunction with multicast messages are for further study.
The go-coap server seems to ignore block1 requests, emitting the error "message is truncated", since it's not anticipating a block1 request, but block2 seems to work for me with multicast?
JKRhb
shamblett
In the current version of the library, using multicast with block-wise transfer currently does not work anymore, as the client checks if the response's token matches the one of the original request.
https://github.com/shamblett/coap/blob/3f03f45e66ca4102ce729a95a0477fab4acd1292/lib/src/coap_client.dart#L474
However, because the client switches to unicast when using block-wise transfer with a server, this check always returns
falsebecause a new token is assigned once the switch is made. I will try to come up with a fix for this problem in the next couple of days.Maybe the check could simply return
trueif multicast is being used, like so?Or could we add a field for an "original token" somewhere, which could be used for matching instead?