I looked again at the unicast issue, and here is what I found. * 1588 has a very complex unicast subscription protocol (16.1). This is similar to what you have in this series, and so if we do it right then we will have a good basis for adding this later.
* 1588 also allows basically any kind of unicast you might want (7.3.2). This probably the reason why other PTP implementations just implement whatever they dream up, ignoring (16.1). * The enterprise profile [1] forbids using (16.1). Instead it has the master send unicast delay responses to unicast delay requests and use multicast when the delay request is multicast. 1. http://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ So getting back to this patch, I would like to see this: > Or how about this: Let transport_send accept an optional pointer to > an address structure. Also, transport_recv could always return the > source address, and we won't need a separate "get last address" > function. This means using recvfrom in the transports. Also, the struct ptp_message should have a new field to hold the source address. Let us introduce a struct to hold addresses, something like: struct address { uint8_t buf[MAXADDR]; socklen_t len; } In that way we won't need to add 'addr' and 'len' all over the place, and if we end up needing the interface index, it will be easy to add later on. Does this make sense to you? If not I'll whip up a patch to show what I mean. Thanks, Richard ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
