GithubHelp home page GithubHelp logo

udp suggestions about erldns HOT 3 CLOSED

dnsimple avatar dnsimple commented on August 20, 2024
udp suggestions

from erldns.

Comments (3)

aeden avatar aeden commented on August 20, 2024

Thanks for the suggestions.

Given {active, once} mode, the larger buffer is essentially unnecessary since there will only be one packet in the buffer at any given time, correct? The typical DNS packet size is 512 bytes, unless EDNS specifies a larger size. Even in that case the typical packet size will still be less than the default 8k size used in Erlang.

So in the current setup the default buffer size is fine.

Now, let's consider if I switched to {active, 100}. In this case the buffer size would need to be larger. My understanding of {active, N}, based on http://www.erlang.org/doc/man/inet.html#setopts-2 , I would need to also listen for the {udp_passive, Socket} message and set {active, N} again. I'm not sure how much of a gain we'd get by letting the socket buffer, but I may try some testing.

Finally, regarding inet_udp:send versus gen_udp:send, are there any drawbacks?

from erldns.

SergejJurecko avatar SergejJurecko commented on August 20, 2024

About buffers you are very wrong. This is kernel space reserved for
incomming packets. Nothing to do with active setting.

Once it is full (because they were not processed fast enough) every arrived
udp packet is dropped. I had this problem on every project I used udp in
erlang. It was always filling up.

The difference in inet_udp is that IPs must be in tuple form. That timer is
so that it tries to resolve address in list form. But if it is tuple it
just sets timer, noop then cancel. Unfortunate design.
On Jan 21, 2016 23:31, "Anthony Eden" [email protected] wrote:

Thanks for the suggestions.

Given {active, once} mode, the larger buffer is essentially unnecessary
since there will only be one packet in the buffer at any given time,
correct? The typical DNS packet size is 512 bytes, unless EDNS specifies a
larger size. Even in that case the typical packet size will still be less
than the default 8k size used in Erlang.

So in the current setup the default buffer size is fine.

Now, let's consider if I switched to {active, 100}. In this case the
buffer size would need to be larger. My understanding of {active, N},
based on http://www.erlang.org/doc/man/inet.html#setopts-2 , I would need
to also listen for the {udp_passive, Socket} message and set {active, N}
again. I'm not sure how much of a gain we'd get by letting the socket
buffer, but I may try some testing.

Finally, regarding inet_udp:send versus gen_udp:send, are there any
drawbacks?


Reply to this email directly or view it on GitHub
#37 (comment).

from erldns.

aeden avatar aeden commented on August 20, 2024

Implemented two of the three suggested changes with #61

from erldns.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.