Server Treats NON-Message as CON-Message about californium HOT 17 CLOSED

Faced with the same issue, used

 client.useNONs();

I will look through code why Type.NON is ignored.

from californium.

Hi Eugene,

client.useNONs() seems to work.

Thanks,

James

On Wed, Jul 20, 2016 at 4:36 PM, Eugene Nikolaev [email protected]
wrote:

Faced with the same issue, used

client.useNONs();

I will look through code why Type.NON is ignored.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#75 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADkRp3McgjqeHWWSIPIe4ORZxoNctZ5sks5qXjJsgaJpZM4JQvg1
.

James Nguyen
Email: [email protected]

from californium.

A pull request has been added.

from californium.

I just did a git pull. Nothing has been updated.

On Wed, Jul 20, 2016 at 7:09 PM, Eugene Nikolaev [email protected]
wrote:

A pull request has been added.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#75 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADkRp6w7X3vpjRyF3iR75uXVFgErPIHZks5qXlZQgaJpZM4JQvg1
.

James Nguyen
Email: [email protected]

from californium.

from californium.

CoapClient's send() methods indeed set the request type to the client's configured default type (set via CoapClient.useNONs() or CoapClient.useCONs() as you already figured out). If you want more control over the specifics of the request you should use CoapClient.advanced(Request) for sending synchronously or CoapClient.advanced(Request, CoapHandler) for sending asynchronously instead.
These methods only set the passed in request's URI to the target URI set for the client.
I currently tend to therefore close this issue and the related PR unless you still feel that Californium should behave differently ...

from californium.

Thanks for reply!

Not sure if I 100% understand the points, but in my case, CoapCliient#advanced uses CoapClient#asynchronous (or synchronous) which uses CoapClient#send.
So Request#type is never applied and it looks strange in the code:

        CoapClient client = getClient(path);
        client.useNONs();
        Request request = new Request(code, Type.CON);
        ...
        client.advanced(request);
        // Actually the request will be CON

from californium.

Yes, I manually set the request and used client.advance() method, but the server treated the non-confirmable message as if it was a confirmable message.

On Jul 21, 2016, at 9:08 AM, Kai Hudalla [email protected] wrote:

CoapClient's send() methods indeed set the request type to the client's configured default type (set via CoapClient.useNONs() or CoapClient.useCONs() as you already figured out). If you want more control over the specifics of the request you should use CoapClient.advanced(Request) for sending synchronously or CoapClient.advanced(Request, CoapHandler) for sending asynchronously instead.
These methods only set the passed in request's URI to the target URI set for the client.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from californium.

I could bear with it but it is not so convenient if client operations are incapsulated like this:

    void nonPut(String path, byte[] payload)  {
        performRequest(path, payload, Code.PUT, Type.NON);
    }

    void conPut(String path, byte[] payload)  {
        performRequest(path, payload, Code.PUT, Type.CON);
    }

    ...

So somewhere in the performRequest I have to have an if with useCONs/useNONs in clauses.
Though of course it's minor.
But I think such issues would be created multiple times because of confusion.

from californium.

Indeed, it is not.

I'd rather users more control of Request.

On Jul 21, 2016, at 10:07 AM, Eugene Nikolaev [email protected] wrote:

I could bear with it but it is not so convenient if client operations are incapsulated like this:

void nonPut(String path, byte[] payload)  {
    performRequest(path, payload, Code.PUT, Type.NON);
}

void conPut(String path, byte[] payload)  {
    performRequest(path, payload, Code.PUT, Type.CON);
}

...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from californium.

@evgeniynickolaev,

after taking another look at the code, I guess you're right. the advanced() methods also delegate to the same send() method :-(
I guess we should move the request.setType() from send() to the convenience methods (post(), put(), get() etc) then. This way, client code can use the advanced() methods for sending a request that it has configured manually whereas the convenience methods can be used in the established way, e.g. by less experienced users. AFAIK we should also make sure that the target URI can be set explicitly when using advanced().

What do you think?

from californium.

@sophokles73 ,

Oh, yes, I see your point, it will be great and will solve the issue.

But CoapClient#send should anyway set the type if Request#type is null otherwise we can break some legacy code.

May I make another pull request?

from californium.

That's true, however, this issue already came up in another context (TCP support) and we thought that it seems strange that we even allow for a Message being created without a type being set/supplied. I think we should tackle the issue at its source and set the type to e.g. CON by default in the Message constructor ...

from californium.

So I should also add CON by default to the Message. OK, I like it.

from californium.

That'll be helpful. :)

On Jul 21, 2016, at 12:01 PM, Eugene Nikolaev [email protected] wrote:

So I should also add CON by default to the Message. OK, I like it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from californium.

I've added a new pull request

#78

from californium.

I've added a pull request with the review comments applied.

#79

@sophokles73, could you please revise it?

from californium.