You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of a blockwise FETCH (bock2 only) sends the payload only in the first request. The follow up request do not contain the payload. With that, it's not possible to implement a stateless sever. Changing that, will require more data volume.
When Californium acts as server, Californium uses the client's identity (maybe the ip-address or the principal, depending on some configuration) and the URI including the URI-query to match a blockwise transfer. Since version 3.9, PR #2161 added also the message code to that. Californium's uses state for its implementation.
For a mixed block1/block2 transfer this seems to be unclear, what the best behavior will be.
If you're interested, please write us, what your preference will be.
The text was updated successfully, but these errors were encountered:
See the discussion in PR #2088 and Send request body when requesting Block2 messages for some more details.
The current implementation of a blockwise FETCH (bock2 only) sends the payload only in the first request. The follow up request do not contain the payload. With that, it's not possible to implement a stateless sever. Changing that, will require more data volume.
When Californium acts as server, Californium uses the client's identity (maybe the ip-address or the principal, depending on some configuration) and the URI including the URI-query to match a blockwise transfer. Since version 3.9, PR #2161 added also the message code to that. Californium's uses state for its implementation.
For a mixed block1/block2 transfer this seems to be unclear, what the best behavior will be.
If you're interested, please write us, what your preference will be.
The text was updated successfully, but these errors were encountered: