Comments (12)
@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.
from coap-rs.
Hey @ptxmac, could you provide an example of why the SocketAddr would be useful? Just trying to understand the use case.
from coap-rs.
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.
from coap-rs.
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.
from coap-rs.
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
from coap-rs.
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?
from coap-rs.
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
from coap-rs.
@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.
from coap-rs.
@jamesmunns Agreed. Object-oriented make the code more flexible.
from coap-rs.
@ptxmac Please let me know if this meets your needs:
#9
from coap-rs.
@ptxmac will be merging soon. Please let me know if you have any concerns
from coap-rs.
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.
from coap-rs.
Related Issues (20)
- Generic subject observer (RFC 7641) support HOT 5
- Server::run abruptly returns when a response payload is too large HOT 4
- Observe requests crash server if the client uses an empty vec![] to represent Observe: 0
- Migrate to Rust 2021 edition HOT 1
- Updating observes from server? HOT 10
- Crash when using python aiocoap HOT 2
- Unexpected panic due to network connectivity state HOT 1
- Outdated documentation refrenced HOT 1
- Message IDs and tokens not set HOT 2
- Client: Separate responses not processed HOT 2
- GET, POST etc. with Uri-Host HOT 2
- Blockwise transfer for with a request payload HOT 4
- Server response retransmission due to duplicate client request (duplicate MID) HOT 3
- Update coap-lite dependency HOT 2
- 0.12.2's update of coap-lite is incompatible HOT 1
- No easy way to set options in client requests HOT 8
- The observer implementation and my use case HOT 7
- Mio 1.8.8 incompatible with newer Tokio versions HOT 3
- observe uses hard-coded default receive timeout HOT 1
- Inject/queue a notification for the Server to dispatch HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coap-rs.