Pass socket to handler callback
Closed this issue · 12 comments
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.
Hey @ptxmac, could you provide an example of why the SocketAddr would be useful? Just trying to understand the use case.
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.
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.
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
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?
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
@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.
@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.
@jamesmunns Agreed. Object-oriented make the code more flexible.
@ptxmac will be merging soon. Please let me know if you have any concerns
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.