nzsmartie / coap.net Goto Github PK

I have a requirement where I need to server to know the origin of the request - the RemoteEndpoint.

The ICoapConnectionInformation is not forwarded from CoapResourceHandler.HandleRequestAsync method to the CoapResource.
I guess it would be a nicer solution if the ICoapConnectionInformation was forward as part of the CoapMessage.

Leaving this here as a reminder for later. https://github.com/Azure/DotNetty

If two contexts are awaiting CoapClient.RecevieAsync(), A newly received message is dequeued and only returned to one of the awaiters. this can become problematic in situations such as using a CoapBlockStream instance that's reading from a CoapClient. it'll drop all messages not intended for the block-wise transfer and may miss out on important blocks if they are received elsewhere.

A proposed solution is making ReceiveAsync subscribe to a observable underneath.
The observer pattern allows all subscribers to receive the same message when it's pushed out.

Section 3.1 of [RFC7252] Specifies that each option instance must be encoded in order of their option numbers.

What's not stated in that section but also very important is repeated options must have their order's preserved. (Take UriPath for example).

Perhaps I'm not fully understanding the design, but it CoapClient's lifecycle must be 1:1 with CoapEndpoint. I was expecting a scenario where CoapEndpoint could be a singleton, but multiple CoapClients could come and go.

Based on CoapClient's Dispose code, this is not the case, and my own results confirm it - too many receive async workers stack up and step on each other.

If this is a necessary design choice, then by all means let's do it this way. However, I think it makes more sense to scope CoapClient to be easily transient. What do you think?

EDIT: I may be confusing the notion of ICoapEndpoint with a transport when really perhaps it should be though of as more of an addressing mechanism?

The tests cases for the CoapBlockTests are generated for each test case, however, they are difficult to re-purpose for integrated test cases.

Message.Deserialise(...) assumes a non-mutated, perfectly formatted message is provided.
If invalid data is provided, it will still try to parse the data and possibly have a fatal failure.

The CoAP specification clearly states multiple scenarios that need to be checked and reject or ignore the message.

It seems that it's not possible to cancel a CoapClient ReceiveAsync call by cancling the CancellationToken.

The majority of the unit tests pass, but random tests will fail. I suspect this is due to race conditions.

This is an outline of my progress of implementing RFC 7959.

Note: Block1 is request payload to a resource. Block2 is a response from a resource.

CoapClient

• Block1
  • Sending messages
  • Reduce block size on response
  • Restart Block-Wise transfer on block 0 when received a 4.14 - RequestEntityTooLarge
  • Fail Bloc-kWise transfer on when received a 4.14 - RequestEntityTooLarge
  • Reduce re-transmit attempts
• Block2
  • Receiving messages
  • Cancel receiving

CoapServer

• Block2
  • Respond with block-wise transfer.
• More to add soon

Hi, first of all I want to say thank you for the library. I'm a bit of a CoAP nut (see https://github.com/malachi-iot/mc-coap ) and we are utilizing your lib to talk over a fully custom network transport.

We are encountering a mysterious problem where MID (and some other portion, I'm sure) maybe don't match up on responses so we end up doing a ton of retries. I am rather confident this is due to some failing of our own ICoapEndpoint, but I was wondering if you could share any wisdom or thoughts?

Inspection of MID's themselves appear to all be proper

Full disclosure: I write the ICoapEndpoint before realizing that it's an endpoint and transport at once, so all incoming traffic is funneling through one singleton ICoapEndpoint and one singleton CoapClient. However, all these tests are against only one target, so hopefully in the short term that's not too bad. I plan to remedy that scenario in the next round of coding

When utilizing a specialized ICoapEndpoint transport layer, what begins as:

UriPath: v1
UriPath: version

in CoapMessage becomes swapped in the outgoing bytes in the CoapPacket I receive during ICoapEndpoint.SendAsync service call. i.e. version appears before v1. UriPath is output in expected order when using Udp endpoint.

Roll a unit-y test just utilizing CoapOption list + CoapMessage.GetBytes to reproduce the issue but that spat out options in expected order. So I'm kinda stumped

It's definitely reproducable in our executing program that we're writing

Current implementation of CoapUdpEndPoint does not support IPv4 and IPv6 at the same time.

Actually the default constructor CoapUdpEndPoint is hardcoded to IPv4 with the IPAddress.Any (Any means IPv4 and IPv6Any means IPv6)
The samples was ailing due to this, so I set out to figure out why and lean myself. So I wrote a blog post:
http://www.lybecker.com/blog/2018/08/23/supporting-ipv4-and-ipv6-dual-mode-network-with-one-socket/

Need to go through all the the public API and ensure it is documented for application consumption. The docs will be updated with each release.

Documentation Progress

• CoAPNet
  • Coap
  • CoapClient
  • CoapClientException
  • CoapEndpoint
  • CoapEndpointException
  • CoapException
  • CoapMessage
  • CoapMessageCode
  • CoapMessageCodeClass
  • CoapMessageFormatException
  • CoapMessageType
  • CoapOption
  • CoapOptionException
  • CoapOptionExtensions
  • CoapPacket
  • CoapReceiveResult
  • CoapRegisteredOptionNumber
  • CoapResource
  • CoapResourceMetadata
  • CoreLinkFormat
  • ICoapConnectionInformation
  • ICoapEndpoint
  • ICoapHandler
  • ICoapTransport
  • ICoapTransportFactory
  • MessageExtensions
  • Options
    • Accept
    • ContentFormat
    • ContentFormatType
    • ETag
    • Factory
    • IfMatch
    • IfNoneMatch
    • LocationPath
    • LocationQuery
    • MaxAge
    • ProxyScheme
    • ProxyUri
    • Size1
    • UriHost
    • UriPath
    • UriPort
    • UriQuery
  • OptionType
  • Utils
    • AsyncAutoResetEvent
    • CoapMessageUtility
    • CoapUri
• CoAPNet.Server
  • CoapHandler
  • CoapLoggingEvents
  • CoapResourceCoreListing
  • CoapResourceHandler
  • CoapServer
• CoAPNet.Udp
  • CoapConnectionInformation
  • CoapUdpEndPoint
  • CoapUdpLoggingEvents
  • CoapUdpTransport
  • CoapUdpTransportFactory