Making PacketConn a first class citizen in Caddy
So I still believe adding PacketConn to Caddy is the easiest (at least for me) to get UDP support.
This means adding https://github.com/miekg/coredns/blob/master/server/server.go#L307 to Caddy and
also https://github.com/miekg/coredns/blob/master/core/restart.go#L87 and extending the Server interface.
@matt If OK, I’ll work and it and prepare a PR.
Would the PacketConn replace the Listener instead of having both? Listeners for graceful servers can be reduced to an
*os.File, which it looks like the PacketConn is too.
Sorry, not following… don’t we then have the reverse problem?
Oh, yup, you’re right I think. That’s what I get for trying to be smart after midnight.
I say go for it and open a PR when you have the chance; that’ll be good to give something concrete to review! Thank you!
Ok, will do. Prolly have something ready in the nex two days.
Another question, related to this. If I were to write a FTP server and I need two TCP ports, 19 and 21 (IIRC), how would that work? IOW: Even if we add PacketConn, I also think we should with
net.PacketConn in the end. I’m not proposing we do this right now - but the discussion might come up in the future. (Or maybe a MultiServer interface could be defined for this use-case).
We could I suppose, though traditionally I associate the concept of a Server with just one listener (or PacketConn) – so if you open two listeners you just create two servers. But definitely feel free to experiment anyway and we can review it in a PR! (Maybe two different PRs, one for PacketConn, the other for net.Listener and net.PacketConn.) Make sure to test the graceful restarts so that we don’t break those.