search

chrysn / aiocoap

The Python CoAP library
Other
261 stars 119 forks source link

Question about UDP transport #39

Open aellwein opened 8 years ago

aellwein commented 8 years ago

Hi @chrysn,

i am experimenting on tunneling CoAP packets through another transport protocol / framework. There is a question: is it possible to completely disable internal UDP transport and use another one instead? P.S. found the text dumper which is also implemented as transport, but is there a way to completely disable the UDP?

chrysn commented 8 years ago

On Mon, Jun 13, 2016 at 08:11:07AM -0700, Alex Ellwein wrote:

i am experimenting on tunneling CoAP packets through another transport protocol / framework. There is a question: is it possible to completely disable internal UDP transport and use another one instead?

The setup of transport implementations is not really flexible yet because there has not been any contender byt UDP6. If you develop in a way that means not using UDP6, I suggest first brutally changing UDP6 to whatever you are using in protocol.py, and then we'll think about how to select them cleanly. (Currently I'd lean towards the create_{client,server}_context classmethods taking a positional transport argument that adds the given interfaces.TransportEndpoint implementation by default -- would you have a use case for pluggable transports?)

P.S. found the text dumper which is also implemented as transport, but is there a way to completely disable the UDP?

The text dumper does not really interact with the transports; it sits a level lower wrapping an asyncio protocol and not a CoAP transport. (It's bad enough that it needs to make pcap-ng fake UDP and IP headers; a dumping transport wrapper might be handy, but I wouldn't know of an "abstract CoAP messages" data format it could dump to.)

aellwein commented 8 years ago

(Currently I'd lean towards the create_{client,server}_context classmethods taking a positional transport argument that adds the given interfaces.TransportEndpoint implementation by default -- would you have a use case for pluggable transports?)

Well, i don't know if it is a general case of a pluggable transport. I have some software (and hardware) components which are doing the data transport over the radio (LoRa protocol), so they allow me the put in an arbitrary payload to transport to the server and back. My idea was to tunnel the CoAP messages, that's why i thought aiocoap put the messages in for me, if it's not too much effort at all.

chrysn commented 8 years ago

On Mon, Jun 13, 2016 at 09:06:26AM -0700, Alex Ellwein wrote:

Well, i don't know if it is a general case of a pluggable transport.

That was phrased badly by me: I'm unsure if we need runtime pluggable transports. I'm positive we do need different implementations of the transport interface.

I have some software (and hardware) components which are doing the data transport over the radio (LoRa protocol), so they allow me the put in an arbitrary payload to transport to the server and back. My idea was to tunnel the CoAP messages, that's why i thought aiocoap put the messages in for me, if it's not too much effort at all.

That sounds interesting (LoRa has shown up on my radar, but seemingly not supporting IP, never got my attention). Let me know before you get stuck, having non-default transports is important for aiocoap. (I'd like to add TCP and websockets, but it might be some time until I get to it; DTLS is probably pointless before https://github.com/rbit/pydtls/issues/6 is fixed).

chrysn commented 7 years ago

Note to self: while PyDTLS still doesn't support the required DTLS version, FlexTLS does.