Hi Christian, Please see inline below.
Best, Chris > On Mar 26, 2018, at 6:28 AM, Christian Amsüss <[email protected]> wrote: > > 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? No. Such details are hidden beneath the API. Retransmission, for example, would be something you specify on a per-message basis. > > (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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
