eclipse-archived / californium.core Goto Github PK

@hnaidin and @jvermillard motivated support for an Observe mapping, for instance, through Web Sockets or streaming.

Hi,
I'm experimenting a problem with my project including californium lib.
I added repositories and dependency in my pom.xml. Compilation is OK. But when I run the application there is the following error
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/californium/core/CoapClient
I noted that in lib folder there is the file californium-core-1.0.0-SNAPSHOT.jar but in MANIFEST.MF in classpath it's reported as
lib/californium-core-1.0.0-20140715.144519-3.jar (the last part changes at any new recompilation date/hour).
Changing manually the path in MANIFEST.MF the previous problem is fixed but I have

Create standard properties with file Californium.properties
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/californium/elements/Connector

Maybe I'm missing something. Can you help me?
Thanks

I always get the following error while using cf-secure, was trying to setup a CoAP server with DTLS

14 WARNING [Record]: Received illegal record content type: 68 - (ch.ethz.inf.vs.scandium.dtls.Record.java:192) fromByteArray() in thread DTLS-Receiver0.0.0.0/0.0.0.0:5683 at (2014-09-28 13:53:13)

When we send corrupted coap frame, eg. invalid header inside we get auto-generated response by library and we can't change payload ("Observe option must...")

In my opinion good option is add customize handler on invalid data on coap layer.

00:31:41.016,000] CellGtw: SOCKET RECEIVE
[00:31:41.017,000] CellGtw: Packet received
[00:31:41.017,000] CellGtw: 64 82 1E 90 93 98 58 08|d.....X.
[00:31:41.017,000] CellGtw: FF 4F 62 73 65 72 76 65|.Observe
[00:31:41.017,000] CellGtw: 20 6F 70 74 69 6F 6E 20| option
[00:31:41.017,000] CellGtw: 6D 75 73 74 20 62 65 20|must be
[00:31:41.017,000] CellGtw: 62 65 74 77 65 65 6E 20|between
[00:31:41.017,000] CellGtw: 30 20 61 6E 64 20 31 36|0 and 16
[00:31:41.017,000] CellGtw: 37 37 37 32 31 35 20 28|777215 (
[00:31:41.017,000] CellGtw: 33 20 62 79 74 65 73 29|3 bytes)
[00:31:41.017,000] CellGtw: 20 69 6E 63 6C 75 73 69| inclusi
[00:31:41.017,000] CellGtw: 76 65 |ve
[00:31:41.017,000] BrS: Communication is successful

Californium requires proper groupcomm support. There exist some forks that add this, but there are no pull requests yet. Anyone in?

I use californium with scandium for security.
I want to implement some ACL or behavior based on the identity used for the DTLS authentication (PSK identity, or the public key or certificate).
For that I need to be able to retrive DTLS session identity information from the CoapExchange or Request object passed to the handleXXX() methods.

CoRE Link Format attributes are a common feature in CoAP, so LinkAttribute should be in the base module californium-core.

How to do logging and how to improve it? There are two types of logging for Californium:

1. Internal logging to get the Californium implementation right. This is usually only of interest for the Californium team and when developing extensions. For now, we just use java.utils.logging here, which is not great, but there is also no alternative that stands out.
2. Operational logging to see what is going on. This is what users of Californium want to have in their logs. For this, it is best to disable the internal logging completely and use MessageInterceptors (see MessageTracer as example implementation). Just implement your preferred logger in a custom Interceptor and add it to the Endpoint. It will receive then log every message that enters and leaves the system. Additional custom logging could be done in your CoapResource implementations.

To improve this concept, it would be great to know if there are other things that are interesting during operation.

In the long-run, we might also want to change the internal logger. Maybe we can align the logger implementation over multiple IoT Eclipse projects or at least find something that is good for all Californium committers.

Hi,
I'm trying to create a plugin for our domotic framework www.freedomotic.com but I have a problem with maven dependencies.
Following your instructions on homepage I added the two repositories but they have the same and compilation fails with
The project com.freedomotic:coap-client:3.0 (/home/mauro/Scrivania/fork/freedomotic/plugins/devices/coap-client/pom.xml) has 1 error
'repositories.repository.id' must be unique: repo.eclipse.org -> https://repo.eclipse.org/content/repositories/californium-releases/ vs https://repo.eclipse.org/content/repositories/californium-snapshots/ @ line 55, column 17

Using only one repository there is always an error
Failed to execute goal on project coap-client: Could not resolve dependencies for project com.freedomotic:coap-client:jar:3.0: Failure to find org.eclipse.californium:californium-core:jar:1.0.0-SNAPSHOT in https://repo.eclipse.org/content/repositories/californium-snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of repo.eclipse.org has elapsed or updates are forced -> [Help 1]

Can you help me?
Thanks

Add convenience support for ETags to ResourceBase or wherever applicable, so that there is out-of-the-box validation support (GET+ETag -> 2.03 Valid). The developer will need to define a hash method or otherwise register the current ETag for the resource.

The BlockwiseLayer could automatically set the Size options.

When using coap observe, server send notification in a confirmable or non confirmable way.
To stop the observation client should respond with a reset message.
But Reset messages are transmitted unreliably, the client must be prepared that its Reset messages aren't received by the server. (draft-ietf-core-observe)

Maybe client should always send a Reset Message to unexpected non-confirmable message.

I'm not sure but It seems that's what you try to do here.
But sendEmptyMessage seems to not send any RST message and exchange is always null.

(linked to leshan issue)

When requested out-of-order, Cf can skip the (atomic) buffering and just return the block without creating transfer state for the client.

The HTTP cross-proxy is currently broken.

• Single-threaded handling prevents concurrent requests and losses of CoAP messages cause the proxy to freeze until the messages time out.
• Caching does not work properly
• Check correct handling of options when Proxy-Uri or Proxy-Scheme is set

HTTP needs to become an Endpoint implementation and requires integration into the Exchange concept.

Content-Format and Accept handling is currently fully up to the resource implementer. Californium could provide an Accept option check before delivering requests or check the Content-Format after a request was processed and could automatically react with 4.06 Not Acceptable.

This could be added as Layer for the CoapStack.