Retransmission and new server API #22
Conversation
Spawn a go routine for each CoAP Confirmable message. Will resend if needed following the RFC backoff pattern.
Send response with the request token for matching query/answer. Add the capability to choose between piggy backend answer or seperate acking. Abstract request answering for being able to plug multiple transport (UDP, TCP, websockets, (D)TLS)
|
About piggy backed & separate responses: |
|
Would you be interested in helping maintain this? I don't like having these things sit out too long. I'd rather have someone actively using it push it forward than to hold it back since my needs are met. |
|
Hi, sorry for the delay, august break 😄 Thanks for the rust. Today it's not part of my CoAP stack (I mainly use Californium & Java) but I think I can help maintaining the project. Today my main focus is implementing DTLS with Go, with is a quite long challenge. |
|
I'd be interested in helping maintain @dustin @jvermillard . Any immediate next steps I can help with? |
| // wait for ack or timeout | ||
| timeout := randTimeout() | ||
|
|
||
| for f.retrans < MAX_RETRANSMIT { |
There was a problem hiding this comment.
once f.retrans == MAX_RETRANSMIT don't we want to remove the entry from retrans.inflight? To be more robust in terms of memory consumption against recipients who aren't responding at the application level?
| return s | ||
| } | ||
|
|
||
| func (retrans *Retransmitter) Record(req Message, a *net.UDPAddr) error { |
There was a problem hiding this comment.
do we want to pass in some channel or something so that we can keep track of messages that were never delivered? Or, do we maybe want to provide the option to block until received for clients?
I know this pull-request is a bit disruptive :)
When I implemented retransmission I found some part are missing in this CoAP implementation.
like token correlation, piggy-backed ack, etc..
It's still a work in progress, but I wanted to show it before I change too much of the original project