Hello everyone, this is Peter Menzik and he will tell you why resolving two names in
the GUI program is hard.
If you've ever tried, you know.
If you've never tried, listen.
Okay.
Good afternoon.
My name is Peter Menzik.
I work for Red Hat, so I took my hat with myself and this is a presentation about why
the resolution of two names in a single program is not simple.
So, how do you resolve names?
The system offers get other info call and it is protocol and family independent, requires
just host name and service name and returns and this is somehow ordered and works on major
OS operating systems.
It is fine, but it blocks.
And we don't want that.
We can work on that by using asynchronous libraries, which are usually DNS only.
That might be good enough, but not always and typical applications should not be limited
by that.
So, good for servers, not for workstations.
Because name resolution can be provided also by different providers than DNS only and some
are obsolete, some are not.
So, I think application should try to use common provider for any aim.
We have, for example, system here is of D, which provides different protocols, but does
not work in a way which breaks, for example, DNS only application.
So, it's not a good solution, I think.
So, how do I make multiple solutions from single program?
I can use second interface.
It works for DCP, UDP, present on any system, but I can handle thousands of connections
from single program without problem.
I just use poll or select and select only socket, which has something ready for me.
So, why is blocking problem?
Because graphic applications use not a blocking loop, but just event-based loops.
And they are non-responsive if any call they use blocks.
We want to avoid that.
So, modern applications are implemented by just callbacks to events they want to handle
and nothing else.
And then spend most of time waiting for something and conserve CPU.
So, why not just working threads?
Because creating a new thread is simple, but receiving result from finish to work in thread
into the main thread is not so simple.
And it increases complexity a lot of any application almost.
So, why that thread is needed anyway?
Name resolution on Linux machine can come from multiple modules.
Some are local only on the machine.
Some need to ask local or remote service.
And fetch, send some request and wait for some response.
It may tie or not and extract fetched addresses and return them to start connecting.
And the most important waiting for timeout or activity or socket activity is implemented
by any framework doing non-trivial applications anyway, because they need it.
So, how can it be made non-blocking?
I think we should make a common code to implement protocol specific plugins and DNS should be
only one of them.
And for example, multicast DNS or so and provide integration with custom loops in different
applications because major graphical applications use Qt or G-Lip, but they may use some custom
loops and it should require relatively small time, small code part to integrate with them quite nice.
So, we should rewrite existing modules to use callbacks like modern applications and not
just blocking because current modules are easy to write and maintain but difficult to use
from normal applications.
I think resolution should be simple even in non-trivial applications.
So, what do we need?
Just ability to add and modify socket into watched list of events and denotified after time is up
and if no activity occurred and provide some code to handle those events.
And we don't care too much about time precision because we measure time out in seconds in DNS anyway.
So, who cares?
So, why non-blocking?
Because it creates no race conditions.
It's almost unlimited.
It's limited by number of socket handled that usually quite high, so we don't care.
And it can allow many queries per thread without any problem.
And resolution would become more easy handled in a single thread only, not scattered over
multiple threads during runtime.
So, we should not care and of course, separate threads would still make sense if this intensive
applications are run but for small fetches of data from network it's not necessary.
I think server software should take advantage too.
So, unfortunately, there is no implementation yet.
I think Pavel Shimada wrote quite good start called NetResolve and it provides separate
load-double modules with different providers which can be used as building start.
But its documentation is quite poor and non-blocking API.
I try to start what is needed is missing and waiting for me, I think, to write.
But I think we need protocol independent API for normal applications.
And if we add just some metadata to stroke the other's info provided by Get Other Info today,
I think we could handle also HTTPS resource records in library and not require common applications
to handle that and implement it in each application.
I guess there are many applications starting HTTPS connection and it should be not
re-implemented in every application doing that.
Of course, some parts are similar and for example, multicast DNS can use the similar parts
and could use the same calls with just asynchronous way.
And that is almost all I had to say.
So, are there questions?
No questions?
So, you want a solution for this? Is there a way for Red Hat to lead this in the free desktop space, maybe?
Well, maybe, yes. Who should lead the initiative?
I am not sure. It's not official Red Hat initiative yet.
It's just my own opinion. So, it's not like Red Hat already has project and involved people and such.
So, it's still what I think should be done, but not yet decided who should lead it or who should cover that.
I definitely want to talk about it in Red Hat, but it's in fact not clear to me
which mailing list or organization should start and should organize this because
it's maybe should be handled by G-Lipsy people or I don't know.
I would like to talk and hear what other thing about it because I'm not sure myself.
It occurs to me that this problem statement is a lot like the get DNS problem statement plus things that aren't DNS.
So, I guess my recommendation would be why not look and see if you can enhance that API to include these non-DNS naming systems?
Which API?
Well, the question was why not enhance existing solutions like get DNS for example?
I'm not sure how can you do that because I think that the problem I have with system D trying to do that
is far away.
This is a good example of how to do that wrong because I think when application wants to talk DNS only and nothing else,
it should be able to.
So, if I use the get DNS library and I think it should do only DNS, it should be able to choose.
So, how do I choose whether it's different protocols and how do I forward from get DNS library?
What do we all do from there?
Because I think get DNS expects DNS record types or such things and those are DNS specific.
Those don't work in other protocols.
Does that answer the question?
Well, not so much question as well as how to get DNS address this.
Get DNS for all its faults is extremely flexible.
So, you can enable and disable extensions.
You can say by default it does DNS only if you say I want to have an DNS that starts doing it.
So, there is a way to extend it and the same thing applies to record types.
If you say I have funky record type, it fits within the framework to have it.
So, I think it's a lot of technical problems.
Yes, but look, it wasn't even a question.
Please repeat the comment.
I think statement get DNS is quite flexible and can adjust to those.
Yes, why not?
I don't say we have to implement it from start, but it should be generic enough so it would be future proof.
And I admit I don't know details of DNS, get DNS library, so I can't comment details.
I just ensure it can do, but why not if it's another library,
but I think it eventually should land in Lipsy or something like that after it proves it works.
So, maybe.
So, you had a slide.
Does anybody else have a question?
No?
You had a slide about callbacks near the beginning.
Callbacks.
But it doesn't matter.
Do you expect every plug-in to handle things like TLS or would TLS be something?
I would like to TLS be. TLS is kind of special machine, but it should be somewhere inside.
And what the user should receive should be ready to use socket to work on.
So, he just puts inside the name and service name and it does the heavy machine inside.
Well, TLS socket is something over it.
It's above normal connection, so I think it should be extended.
I'm not sure what should be.
It's above that.
I'm, yes, I am out of time.
Yes, yes.
That's perfect.
Thank you.