| Re: [wakaama-dev] transaction & block wise transfer ready for first comments |
|
Hi David, Thanks for the welcome! Let me start with your second question: “ I don’t get why the blockwise extension is not implemented the same way on the client and the server. Both the client and the server uses the transaction mechanism. Could you explain me?” So far, as I understand, the transaction uses either the mid or the token to match messages. Therefore a transaction can only be used for the COAP-client side to handle bock wise transfers. The COAP-server can’t
use this, because the block wise transfer uses neither mid nor tokens to relate the single block exchanges to the combined payload (see draft-…-16, page 25, statements on the usage of token). Therefore the COAP-server uses the endpoint, method and uri to combine
the blocks (maybe we extend this in the future to the uri query also). Maybe a COAP-client could also use the endpoint, method and uri to lookup the payload and split it into blocks, but though it can use the transaction, I used that. Back to your first comment: During the last weeks working on COAP and wakaama, I got the experience, that may implementations unfortunately ends up much more interrelated than independent. Maybe because I’m new in COAP and new in wakaama,
maybe because the “reality” is also more interrelated than independent. So my plan is, to split of some parts (starting with the bug fixes) and prepare a contribution for that. And when it got integrated (may be even more improved or mixed with other extensions)
or rejected, I would continue to prepare the next contribution (e.g. the transaction without the block wise extensions), and so on. Preparing several contributions in parallel (with the interrelation in mind) seems for me to be a “not working approach”. And so back to my question: “Is the preferred way for this project therefore to report a bug or to list the fixes her in the mailing list?” Mit freundlichen Grüßen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ESY4) Stuttgarter Straße 130 71332 Waiblingen GERMANY Tel. +49 711 811-58139 Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn Von: wakaama-dev-bounces@xxxxxxxxxxx [mailto:wakaama-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Navarro, David Hi Achim, and welcome I read your extensions. Nice work we need indeed. I have two main comments: -
your branch cond_observe contains all the changes. It would be better to have one branch branched from the head of wakaama:master containing only the blockwise extension and another one containing only the transaction
extension. It would be much clearer for the integration. -
I don’t get why the blockwise extension is not implemented the same way on the client and the server. Both the client and the server uses the transaction mechanism. Could you explain me ? On a side note, I just realized there is a potential DOS attack vector with blockwise if a compromised peer keeps on sending packets with the More flag set. We need to limit the storage buffers per
peer. Regards, David Navarro From:
wakaama-dev-bounces@xxxxxxxxxxx [mailto:wakaama-dev-bounces@xxxxxxxxxxx]
On Behalf Of Kraus Achim (INST/ESY4) Hello PL, Committers and Contributors, I’m also new to this list. As my colleague Jörg already announced, I was working the last weeks on some extensions for wakaama.
The first one is an extension of the transaction mechanism. The original one takes the MID and matches an ACK with this. This is working fine for piggybacked responses, but it seems not to work for separate responses.
Separate responses may be useful, if it must be ensured, that the response is already received before sending any further messages. This may help to during the registration process. The second extension is the block wise transfer. Though the spec is still a draft, it may be not the final one. The block wise transfer uses a buffer to accumulate or store larger payload. The COAP client uses transactions
to maintain these buffers, while the COAP server uses a list of buffers identified by client/method/uri triples.
For both extensions please refer to the comments in “transaction.c” and “blockwise.c”
The extensions are now pushed to the
https://github.com/bsinno/wakaama copy of wakaama for comments on it. The diff is unfortunately more the 300KB, so if wanted, I would prepare pull requests with selected smaller subsets (one by one,
J ). I would propose to start with some additional fixes. Is the preferred way for this project therefore to report a bug or to list the fixes her in the mailing list? Mit freundlichen Grüßen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ESY4) Stuttgarter Straße 130 71332 Waiblingen GERMANY Tel. +49 711 811-58139 Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |