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 triggered. Look
for the code just past EVENTIO_DNS_CONNECTION. Therefore removing all of that
code would have no effect on DNS.
This brings up the point of why we would want separate code for UDP and TCP
socket handling. At the polling level they are both file descriptors and I see
no reason any UDP support could not be done directly in the current NetHandler
code (as, indeed, DNS does).
I am not convinced of the utility of maintaining code that is not used and is
not important to users. In all my years working on ATS I have not once heard
any request for UDP based proxying. That may change if QUIC becomes popular but
again in that case we would likely do something more direct.
I do note that in your list of good things about NGINX you don't list UDP
proxying...
On Tuesday, November 3, 2015 9:32 AM, Chao Xu <xuc...@gmail.com> wrote:
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 direction, ats project would be going to the
end if only has it.
a Good project : Nginx, 1st: it is a webserver, 2nd: it is a load balance,
3rd: it is a tcp proxy, 4th: it is a cache, and more and more feature added.
but ATS do less than less ...
Hope the IOCore to be a dedicated project to support TCP and UDP if the
core dev team prepare to remove the udp from ats and ATS still be a
proxy/cache system.
iocore project would be a nice project.
2015-11-03 23:09 GMT+08:00 Alan Carroll <
solidwallofc...@yahoo-inc.com.invalid>:
> 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.
>
>
> On Tuesday, November 3, 2015 12:20 AM, Chao Xu <xuc...@gmail.com>
> wrote:
>
>
> 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 and
> NetHandler: at the beginning of pollEvent(), the code "if
> (likely(net_handler)) {"
> for UDP implement, net_handler is set to NULLfor non-UDP implement,
> net_hander is set to non-NULL
> the PollCont is shared by UDP and non-UDP.
> there would be have duplicate code if we remove PollCont.
> thus, I'm disagree with you, I think PollCont should keep and nethandler
> should call pollEvent and remove dup code.
> Oknet Xu
> 2015-11-02 23:53 GMT+08:00 Alan Carroll
> <solidwallofc...@yahoo-inc.com.invalid>:
>
> 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 <xuc...@gmail.com>
> wrote:
>
>
> 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 mainNetEvent() rather
> than call pc->pollEvent(event, e) from NetHandler::mainNetEvent() ?
>
> Is it a special design ? or just for print "NetHandler::mainNetEvent" in
> debug log ?
>
> Thanks!
>
> Best Regard,
> Oknet Xu
>
>
>
>
>
>
>
>
