gotthardp / gen_coap Goto Github PK

coap_client:request(get, "coap://somehost/api")

This never times out if the host is unreachable. I see that coap_transport has mention of ACK_TIMEOUT so I'm not sure why this won't error.

Any help/ideas would be much appreciated, thanks!

Hello,
can you please explain and give example how clustering is done with CoAP server.

Obviously some of devices will be attached via UDP to one server instance, so I am interested to see how application knows to speak to a good instance of CoAP server to reach a desired device.

If payload is empty, it will give me an unexpected result which is not fllowed by 16#FF.

%% coap_message_parser.erl , line 163
encode_option_list(Options, <<>>) ->
    encode_option_list1(Options);
encode_option_list(Options, Payload) ->
    <<(encode_option_list1(Options))/bytes, 16#FF, Payload/bytes>>.

There is a problem. When encypt CoAP with AES , pads are necessary, But there is no tag to split them after decryption.

I think this is better:

%% coap_message_parser.erl, line 214
encode_option_list([], _LastNum, Acc) ->
    <<Acc/binary, 16#FF>>.

drasko@Lenin:~/coap/gen_coap$ ./coap-server.sh 
escript: exception error: undefined function sample_server:start/0
  in function  erl_eval:do_apply/6 (erl_eval.erl, line 670)
  in call from escript:eval_exprs/5 (escript.erl, line 871)
  in call from erl_eval:local_func/6 (erl_eval.erl, line 557)
  in call from escript:interpret/4 (escript.erl, line 787)
  in call from escript:start/1 (escript.erl, line 277)
  in call from init:start_it/1 
  in call from init:start_em/1 

Rebar3 places .beam binaries into _build/default/lib/gen_coap/ebin/, and not ./ebin

Got following warnings:

src/coap_dtls_socket.erl:47:10: Warning: ssl:ssl_accept/1 is removed; use ssl_handshake/1,2,3 instead

src/core_link.erl:52:5: Warning: http_uri:encode/1 is deprecated and will be removed in OTP 25; use uri_string functions instead
src/core_link.erl:54:5: Warning: http_uri:encode/1 is deprecated and will be removed in OTP 25; use uri_string functions instead

src/coap_responder.erl:30:10: Warning: pg2:get_members/1 is removed; this module was removed in OTP 24. Use 'pg' instead
src/coap_responder.erl:205:13: Warning: pg2:create/1 is removed; this module was removed in OTP 24. Use 'pg' instead
src/coap_responder.erl:206:18: Warning: pg2:join/2 is removed; this module was removed in OTP 24. Use 'pg' instead
src/coap_responder.erl:230:10: Warning: pg2:leave/2 is removed; this module was removed in OTP 24. Use 'pg' instead
src/coap_responder.erl:232:10: Warning: pg2:get_members/1 is removed; this module was removed in OTP 24. Use 'pg' instead
src/coap_responder.erl:233:15: Warning: pg2:delete/1 is removed; this module was removed in OTP 24. Use 'pg' instead

src/coap_client.erl:105:9: Warning: http_uri:parse/2 is deprecated and will be removed in OTP 25; use uri_string functions instead
src/coap_client.erl:126:20: Warning: http_uri:decode/1 is deprecated and will be removed in OTP 25; use uri_string functions instead

Multicast support would be a great for a setup I am planning here at home.

The server part is simple. Just adding the option {add_membership, {{224, 0, 1, 187}, {0,0,0,0}}} to gen_udp:open/2 when we want the server to accept multicast requests. Seems to work fine when I test it. Although I will have to read the rfc a bit better to see if more is required to be spec complete.

The problem arises with the client code in a few areas.

• How the channels work causes problem because the reply comes from a different ip address than the one that the message was sent from.
• It might get multiple replies from different ip addresses.
• Not sure how to route the incoming messages to the correct client request reply.

I'll be happy to code something up and send a pull request. Just wanted to start with a discussion on how it could operate.

I'm having a hard time figuring out how to add options to responses within the resource callbacks. Such as Location-Path/Location-Query in a response to a POST that creates a resource.
I'm looking at adding options as parameters to the callback methods but wondering if I'm missing something.

Hello,
would it be possible to add a small example that explains the request routing in the server and acceding to an appropriate handler for a given URI path.

Currently we have this: https://github.com/gotthardp/gen_coap/blob/master/examples/src/sample_server.erl, and we can figure out if the type of req was GET, POST, PUT, ..., but I see no information how we parse URL string and based on this we call an appropriate handler for this API endpoint.

In general, I would like to understand the CoAP req multiplexer (router) and I would like to see something like this: https://github.com/go-zoo/bone/blob/master/example/001/example.go#L34-L38 as a framework that would enable quick development of the API.

Looks like DTLS is mandatory - at least I can not find an easy way to turn it off.

I would like to test and understand how it all works without DTLS first, then add it after.

Also, on Debian there is not Erlnag 19.2 yet.

Hey @gotthardp, I was looking at https://github.com/gotthardp/gen_coap/blob/master/src/coap_transport.erl#L80-L82 and trying to figure out how the transport gets out of the got_non phase, or how the transport "completes" otherwise.

Would you be able to enlighten me on this? Thanks for the help.

Hi i'm wondering about the status of this library. How much is actually covered ?

Hello，

I Found the processes of coap_channel_sup and coap_responder_sup can't be closed after coap request socket closed.

I test it like:

1. When a client request came, the server creates 4 processes: coap_channel_sup, coap_channel, coap_responder_sup, coap_responder;
2. Process coap_responder was closed first after finished the request;
3. Process coap_channel was closed when the client ack timeout;
4. Processes coap_channel_sup and coap_responder_sup could't closed;
5. The two processed above will not be reused.

The code in file coap_udp_socker.erl is like:
handle_info({terminated, SupPid, ChId}, State=#state{chans=Chans}) ->
Chans2 = dict:erase(ChId, Chans),
exit(SupPid, normal),
{noreply, State#state{chans=Chans2}};

is it right to change it like this?
handle_info({terminated, SupPid, ChId}, State=#state{chans=Chans, pool=PoolPid}) ->
Chans2 = dict:erase(ChId, Chans),
exit(SupPid, normal),
coap_channel_sup_sup:delete_channel(PoolPid, ChId),
{noreply, State#state{chans=Chans2}};

Options in coap_message_parser.erl are less than rfc7252 on page 53. Why?

Since there is no DTLS in Erlang, there is no DTLS in gen_coap for now. The DTLS support is under development by the Erlang/OTP team, so once this is done we add DTLS to gen_coap.