Using Go for NTPsec

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> That sounds like the right ballpark.  Again, if I were working in this area I 
> would be writing hack code to generate numbers.  It's got to have a buffer for 
> each item waiting in the channel.  Does it do an alloc/free on each item or 
> does it avoid that by saving the buffer and reusing it?  We have 3 sizes of 
> packets: no-auth (48 bytes), shared-key (68), and NTS (232).  Can we tell it 
> how much to copy or will it copy worst-case?
> 
> Processing a packet takes a few uSec for no-auth and ~10 usec for NTS.  A 
> single 250ns is not important relative to 10 usec but will be significant 
> relative to a few usec if you do it several times per packet.

Premature optimization.

We should do *nothing* other than writing the simplest, most idiomatic
code possible unless our *measurements* of GC latency spikes show that
they're reaching an uncomfortable frequency.

This measurement is pretty trivial to do.  See

https://golang.org/pkg/runtime/debug/#ReadGCStats

> I still haven't seen how you plan to get the data from the client side to the 
> server side without a lock.  See sample code above.
> 
> The server side does:
>   loop:
>     recv_request
>     get_info
>     fill in reply
>     send_reply
> 
> I suppose you could do it if channels have a peek option. That will take a lot 
> more code.  You will need a main channel and a sub-channel per thread and 
> another thread to copy over.  And then you have to handle the case where a 
> server thread is idle so it's not checking its new-data channel...  Ugh.

Yeah, there's got to be a simpler way than that.  But it's just
borrowing trouble to try to specify the way this far in advance.  The
Phase 1 goal has to be a dumb, literal, unthreaded translation that
comes as close as possible to just transcribing trhe existing C into
Go and exhibits sane sync behavior.

If we never get further than that it will still be a win because no more
buffer-overrun exploits.  But we will.

Dunno about you, but I expect phase 2 (stupid Go to properly idiomatic
Go with fully exploited concurrency) to be a helluva lot of fun.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>