On Sat, 3 May 2014 20:32:01 +0200, Richard Cochran wrote: > 1. It is a good idea to let the client set the duration?
You wanted to get rid of the magic constant in ptp4l, this allowed me to move it to phc2sys ;-) Okay, seriously: I don't think this is a problem. It is limited to UDS and the worst thing that can happen is attempting to send notifications to a client when the client is long dead because it set too big value and crashed. As it is the client who knows when it will be able to renew the subscription, it makes sense to be the client who sets the duration. Obviously, the hyper correct way would be for the server to ack or deny the request based on the duration value and internal policy, similarly to e.g. bandwidth allocation in various protocols. I think it's overkill for this case. > 2. Should we perhaps use a 32 bit field for this? > As is, it allows only 18 hours. I even thought about limiting the maximum value to a hour or so. The client is supposed to renew the subscription, otherwise the time limit would be useless. Jiri -- Jiri Benc ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
