Dear Christian, Thanks a lot for your interest! I see you got a few answers already; I’ll complement with a few more, in line:
> On Mar 26, 2018, at 3:28 PM, 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)? I think “will provide that in a later form” is the right answer here. > * 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? I think our goal is to describe something reasonable: - not too large - yet not entirely "lame" - and implementable I would say that a TAPS implementation should probably be free to provide details such as the one you’re asking for here, but on the other hand, I think we need to set some bounds to the list that will end up in our doc as “a TAPS implementation MUST …” - it’s easy for this list to grow endlessly. *Right now*, your requested ICMP functionality is not in our list. I also suspect that it falls in the category of “can be done under the hood”. Whatever can reasonably be done under the hood should not be exposed in our API. > And last but not least: Is there an implementation of this around I > could experiment with? Yes, we have NEAT: https://github.com/NEAT-project/neat <https://github.com/NEAT-project/neat> - please do play with it ! Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
