My understanding of the code is DNS uses UDP but doesn't use PollCont or the
UDP processing. It schedules itself on the NetHandler thread and puts its
socket file descriptor in the NetHandler epoll() group. You can see around line
497 in UnixNet.cc where NetHandler marks a DNS connection as trig
ATS still have DNS feature，it is depond on UDP protocol.
ATS Project would be smaller than smaller less feature but HTTP If we
remove DNS & UDP.
ATS is named Traffic Server and it‘s architect designed to support
different protocol，UDP and TCP is basic protocol.
proxy/cache is a very narrow direc
As far as I know, ATS does not support UDP proxying which means all of the UDP
support could be removed as well. There has been some talk of QUIC support but
I suspect that would either be a separate handler (ala SPDY and HTTP/2) or
folded in to NetHandler via the work being done for TS-3612.
PollCont is a part of UDP implement, the PollCont is directly put into
ET_UDP.
UnixUDPNet.cc: thread->schedule_every(get_UDPPollCont(thread), -9);
we will duplicate the polling code again on UDP implement if remove
PollCont entirely.
I think the Author of PollCont design it for UDPNetHandler an
I've been looking at that and my preference would be to remove PollCont
entirely. As far as I can tell it exists only to hold the poll descriptor data
which could easily be promoted to NetHandhandler.
On Monday, November 2, 2015 8:14 AM, Chao Xu wrote:
Hi, All!
I'm looking into t
Hi, All!
I'm looking into the iocore source code reading now.
I found the source code from PollCont::pollEvent() is a part of
NetHandler::mainNetEvent()
.
And the PollCont is designed to as a abstract class for I/O polling
operation.
so I have a question: why we duplicate the code in mainNetEve
