Using Go for NTPsec

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> 
> > We don't have a multithreaded server yet.  Worst case we have two threads,
> > and only one can ever reach the critical region in question. Don't borrow
> > trouble! :-) 
> 
> I'm interested in building a server that will keep a gigabit link running at 
> full speed.  We can do that with multiple threads.

Right.  But the way to get there is certainly *not* to try to design
ahead while you're still thinking in a language like C where
concurrent programming is difficult and error-prone.

Once you get used to being able to program in Go's implementation of
communicating sequential processes you'll gave much better tools for
doing concurrency.

> > If we go to using threads more heavily, the idiomaric Go way to handle this
> > problem would be to have a queue that does only the code in window 1.  When
> > you write to the request queue, it would stop GC, do time-critical magic,
> > restart GC, and ship the result on the output queue. 
> 
> That's adding a bottleneck that we need multiple threads to avoid.

Do you know what our actual bottlenecks are? Have you [rofioled them?

> You can't put it on an ouput queue.  Handing it to the kernel it is part of 
> the time critical region.

I meant output *channel*.  With a goroutine spinning on the end of it.

> > I'm not worries about a DDoS. I don't think the protocol machine gives a
> > hostile client or server any way to force hitting that window. 
> 
> I'll work up some numbers if you think that will be interesting.  (It will 
> take a while.  I have to put a system back together.)

Any possibility of a DDoS being feasible is interesting.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>