Hello taps-interface authors,
I was having a look at the work of the TAPS Group on suggestion of
Theresa; my context is as an implementor the CoAP protocol, which is a
primarily UDP based protocol for RESTful interaction in constrained
("IoT") environments (short: CoRE).That protocol is a bit tricky to implement in full on POSIX sockets because it requires that responses be sent from the destination address of the request, and because role reversal (a server that has received requests starts sending requests to the original client) means that even a server needs to receive ICMP errors on messages it sends. While this can be done on POSIX using various socket options and sendmsg/recvmsg, it is not trivial to implement and sometimes badly supported by platforms and language bindings. I've had a look at the abstract API outlined in trammell-taps-interface, and it seems to be suitable for implementing CoAP in a much more straightforward way, but I don't know yet whether it can do the following: * Can the API be instructed that a UDP package shall go out on the same IP and port as a given received package? (CoAP requirement) * Can a listening (pre)connection be used to initiate a connection actively from the listening port? (This is convenient to have because it allows hosts to advertise their server role in a client capacity without needing to transmit their own server address explicitly). * Can the API be used for sending and receiving multicasts (or will provide that in a later form)? * On the topic of DTLS protected connections: Can the API give me a handle to (or representation of) an outgoing packet in its encrypted form, so that I can issue a retransmit at a later time using the same DTLS sequence number? (There are mechanisms being specified with which CoAP can deal with malicious reordering, but those keep track of lost packages. If the packages get retransmitted as-was and get ack'ed, that mechanism can save a few bytes). * For CoAP, it is recommended to introspect an returning ICMP error to see whether it is genuine (the headers match a sent package) and relevant for various reasons (RFC7252 Section 4.2). Will the API provide that detail to the protocol implementor, or can the protocl implementor configure how to treat which errors? And last but not least: Is there an implementation of this around I could experiment with? Best regards, Christian PS. Please keep me in To/Cc when replying, as I am not subscribed to the TAPS mailing list. -- We are dreamers, shapers, singers, and makers. -- Elric
signature.asc
Description: PGP signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
