Pass socket to handler callback

[ptxmac]

For some applications it's necessary to have access to the sender from the callback. It would be useful to have the SocketAddr in the handler signature.

[jamesmunns]

Hey @ptxmac, could you provide an example of why the SocketAddr would be useful? Just trying to understand the use case.

[ptxmac]

Yes, I'm currently investigating rust as a basic for a LWM2M implementation. In the LWM2M protocol the client sends a single message to the server, and then switches from being a coap client to a coap server. The lwm2m server is then expected to send requests back to the client through the address/port the lwm2m client first connected through.

[jamesmunns]

Interesting. Do you just need the SocketAddr, or do you need the whole socket? Also is this a persistent connection? If you return a Some<Packet> from the handler, it will respond directly to the client.

Right now the coap-rs has no built-in ability to have something like a "Context", e.g. where you can maintain state between multiple requests, using something like a token.

[ptxmac]

Having a context would also be useful, but in my case I need the SocketAddr to make a connection back to the port chosen by the client. Essentially lwm2m flips who is the "server" and "client" after the initial message

[jamesmunns]

Do you need the server's port to be the same on your second connection?

e.g.

Machine_A:12345 ---> Machine_B:5683 // Initial request in CoAP
// Mode-Swap occurs
Machine_A:12345 <--- Machine_B:5683 // LWM2M request

If so, you will need to completely stop the CoAP server when the request is made, because you cannot share port 5683 on Machine_B (not a rust specific thing).

I was already thinking about changing the hander signature from fn handler(Packet, Option<Packet>) -> Option<Packet> to something like fn handler(Request) -> Option<Response>, where Request contains something like:

• packet: Incoming Packet
• addr: SourceAddr
• response: Option<Response>
• ?

Would this work for you?

[ptxmac]

When the lwm2m server is talking back to the client it will chose a new random port, so that's not a issue.

I like that signature, it looks like it would be perfect for my needs

[jamesmunns]

@Covertness any complaints with this new signature? I think this would also prevent thrashing of this signature (I've already changed it a couple times)

This will also make it easier to include a "context" handle of some sort for requests.

[jamesmunns]

@ptxmac Started work on this. Feel free to follow along:

https://github.com/jamesmunns/coap-rs/tree/packet-refactor
jamesmunns/coap-rs@rust-format...jamesmunns:packet-refactor

No address in the request yet, but I have the CoAPRequest and CoAPResponse types in place. I want to make it a little more usable first, then I can add the SocketAddr component.

[Covertness]

@jamesmunns Agreed. Object-oriented make the code more flexible.

[jamesmunns]

@ptxmac Please let me know if this meets your needs:
#9

[jamesmunns]

@ptxmac will be merging soon. Please let me know if you have any concerns

[ptxmac]

Yes, that suits my needs I think. My experiments are just starting, so I might find more needs later. But having the CoAPRequest/CoAPResponse structs would make it a lot easier to change later if needed.