Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reg. Developer manual? #306

Open
lakshT opened this issue May 16, 2017 · 15 comments
Open

Reg. Developer manual? #306

lakshT opened this issue May 16, 2017 · 15 comments
Labels

Comments

@lakshT
Copy link

lakshT commented May 16, 2017

While searching I came across
--> Tutorial slides
--> Master's thesis: Scalability for IoT Cloud Services
on http://people.inf.ethz.ch/mkovatsc/californium.php

Is there any other documentation much like a developer manual?

@boaks
Copy link
Contributor

boaks commented May 16, 2017

I'm not aware of such a documentation :-).

There are "demo-apps" included, which shows the usage.

@lakshT
Copy link
Author

lakshT commented May 18, 2017

I'm trying to implement blockwise transfer from CoAP client to server. In demo apps, I cannot find any example which helps in implementing blockwise transfer. Can you please help?

@boaks
Copy link
Contributor

boaks commented May 19, 2017

branch 2.0.x contains a file server, which demonstrates the blockwise transfer.
Yo can use the demo client fort hat.
There are two modes: californium buffers the data for you (that's then one, the file server uses, and the one I would recommend to start with). In the other one your application provides/gets the data in multiple blocks.

@boaks boaks added the question label May 30, 2017
@lakshT
Copy link
Author

lakshT commented Jun 6, 2017

Thanks, I was able to make my blockwise transfer work using the example.
Now I encountered another issue. I am sending 100 consecutive requests from client to server using blockwise transfer. Each request carries a payload of approx 2400 bytes.
When running the code to send 100 request, after around 40 requests are served. The server sends a null response.
When I add a pause delay of 20ms after every request, it works fine. I have no idea what I could be doing wrong or do I have to change some attribute in californium properties in order for my code to work without delay.
I would really appreciate any help.

@boaks
Copy link
Contributor

boaks commented Jun 6, 2017

Sounds strange to me. Just to make sure: which branch are you using?

Each request carries a payload of approx 2400 bytes.

As far as RFC7959, 2.2 defines the SZX, 1024 is the largest payload for blockwise.
Are you familiar with whireshark? May be it's possible to provide a caputer of your traffic?

@lakshT
Copy link
Author

lakshT commented Jun 16, 2017

I am using branch 2.0.x.
By "Each request carries a payload of approx 2400 bytes", I meant that transmission from the client to server has 2400 bytes as total payload to be transfered and as I am using blockwise transfer, I assume that californium would break this for me in multiple requests.
Initially I was working in a single computer, client and server in same machine using inter process communication. When I moved to a network environment. It seemed that this problem was fixed.

But now I face another problem. I am trying to transfer large data approx 3MB using californium. Using blockwise transfer here. While sending the data I get the following warning.

WARNING: Possible MID reuse before lifetime end for token [a6], expected MID 18,453 but received 18,452

and then after waiting for a response from the server for sometime, I receive a null response. The server on the other end receives the data being sent but I don't know whats goes wrong while responding. I would really appreciate any help or suggestions.

I'm sorry I don't have a very good understanding of wireshark.

@boaks
Copy link
Contributor

boaks commented Jun 16, 2017

I'm not sure, what your requirements are and if CoAP fulfils them. If your requirement is to transfer frequently 3MB, I would guess, CoAP is the wrong.

WARNING: Possible MID reuse before lifetime end for token [a6], expected MID 18,453 but received 18,452

There are two situation, which may cause this:

  1. your connection is that fast, that more the 65536 messages per 247s are used.
    Your client repeats the 3MB and so reaches the 65536 messages per 247s are used.
    That's a limitation of CoAP. Throttling is no option, because it's no problem to have
    a fast flush, it's just a problem, if you continue to send that many messages.
  2. your restarted the client using a defined ip-address and port.
    See https://trac.ietf.org/trac/core/ticket/410

So, do you repeat the transfer or do you restart the client?
And have you changed the default configuration? It's usually store in a "Californium.properties".
For blockwise there are three important values:
PREFERRED_BLOCK_SIZE (default 512)
MAX_MESSAGE_SIZE (default 1024)
MAX_RESOURCE_BODY_SIZE (default 2048)

Which values do you use?

The client also uses a request timeout (see CoapClient.setTimeout(long)). It's important, that this timeout is set to a large enough value for a 3 MB transfer.

@sophokles73
Copy link
Contributor

I would also strongly advise against using the transparent blockwise handling of Californium for transferring files of that size because Cf will buffer the whole content in memory until the transfer is complete... Use FTP for transferring files, that's what it's made for :-)

@lakshT
Copy link
Author

lakshT commented Jun 19, 2017

I think timeout was causing the issue. I was changing ACK_TIMEOUT property to change the value of timeout. Later I used "CoapClient.setTimeout(long)", which seemed to fix the issue.
Thanks for help.

@sbernard31
Copy link
Contributor

Is there any reason to keep this issue open ?

@phani50
Copy link

phani50 commented Mar 4, 2019

Californium have any support of throttlling (means per second 10 requests should handle) ?

@boaks
Copy link
Contributor

boaks commented Mar 4, 2019

Californium hasn't a build in throttling. I think, this would depend very much on the use-case.
Just as some hints to think on:

  • throttling the client or the server?
  • throttling based on Resource or Endpoint?

In the end it's much easier, to implement that on the application layer. Either by control the request (obey the n-start 1 rule in the client application would be a good point to start), or delaying the response, if that makes sense.

@phani50
Copy link

phani50 commented Mar 4, 2019

Throttling for server, based on source.

example : per source(ipaddress) per day 200 requests. if requests exeeds 200 drop those requests.

@boaks
Copy link
Contributor

boaks commented Mar 7, 2019

As already written above, that is not implemented.

If you want to implement it on your own, I would recommend that you replace the ServerMessageDeliverer of the CoapServer by your own implementation, may be your replacement extends that class and overrides preDeliverRequest.

@boaks
Copy link
Contributor

boaks commented Jan 12, 2022

I've started to provide some documentation. FMPOV, javadoc is still the best place to put the details. For an overview I added now some readmes.

DTLS
CoAP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants