Question about UDP transport about aiocoap HOT 4 OPEN

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.)

from aiocoap.

(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.

from aiocoap.

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
rbit/pydtls#6 is fixed).

from aiocoap.

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

from aiocoap.