WEBVTT

00:00.000 --> 00:18.000
So it's about deaf-cut and replication, first of all, who's actually running deaf-cut with replication enabled?

00:18.000 --> 00:22.000
Okay, so it's still some.

00:22.000 --> 00:26.000
Anybody already got rid of it? Because of it.

00:26.000 --> 00:32.000
Okay, so at least I'm actually affected by this.

00:32.000 --> 00:36.000
Why are we here today? Roughly two years ago,

00:36.000 --> 00:40.000
deaf-cut actually removed replication from the open source product.

00:40.000 --> 00:50.000
So until deaf-cut 2.3, we had a very nice replication feature, which worked active,

00:50.000 --> 00:54.000
but now it's gone. So there's different assumptions.

00:54.000 --> 00:56.000
Why this happened?

00:56.000 --> 01:04.000
Some assume that in the past there actually have been some difficulties with the replication code,

01:04.000 --> 01:06.000
and that it's just maintenance burn.

01:06.000 --> 01:12.000
You could assume that they actually want to pitch their commercial product,

01:12.000 --> 01:18.000
because this is of course interesting for the enterprise users, who need the highest possible availability.

01:18.000 --> 01:24.000
But availability? Why me?

01:24.000 --> 01:26.000
I'm doing here by net-less fleet management.

01:26.000 --> 01:32.000
I'm doing this for about 10 years now, so very few emails stuff involved here.

01:32.000 --> 01:36.000
Before that, I did study at the University of Constance,

01:36.000 --> 01:40.000
I have a master in computer sciences,

01:40.000 --> 01:46.000
but in between there's actually been two years of main administration at the university's

01:46.000 --> 01:50.000
computer department, and yeah.

01:50.000 --> 01:54.000
Once running, you know,

01:54.000 --> 02:00.000
mail service in a large scale, you end up running mail service in small scale.

02:00.000 --> 02:04.000
So I'm hosting my own mail setup.

02:04.000 --> 02:08.000
You might get it, as I'm otherwise doing Kubernetes fleet management.

02:08.000 --> 02:12.000
It's on top of Kubernetes to its sites, active, active, whatever.

02:12.000 --> 02:16.000
Duff code replication is lovely for this.

02:16.000 --> 02:24.000
So I kind of actually need it, because this is at home in my basement, in my parent's basement,

02:24.000 --> 02:30.000
with a slow links in between, so low availability, high latency,

02:30.000 --> 02:36.000
all the traditional stuff doesn't work here.

02:36.000 --> 02:46.000
Let's look at replication in Duff code until 2.3.

02:46.000 --> 02:50.000
I think the most central part is actually decent.

02:50.000 --> 02:56.000
Duff aid, you can call it manually with Duff aid in decent, which is

02:56.000 --> 03:00.000
bidirectional or unidirectional as you like it,

03:00.000 --> 03:04.000
synchronization between Duff code and another IMAP server.

03:04.000 --> 03:08.000
It's actually used pretty widely also for migration tasks.

03:08.000 --> 03:12.000
For backup, you can do a lot of nice stuff with it.

03:12.000 --> 03:16.000
It has built in conflict resolution, which is helpful.

03:16.000 --> 03:20.000
For example, if you're doing some migration tasks, you start replicating,

03:20.000 --> 03:24.000
like we had in the last talk, a few some files in mailboxes,

03:24.000 --> 03:26.000
with a lot of mates in there.

03:26.000 --> 03:30.000
It takes some time, and so you kind of finish this within some minutes,

03:30.000 --> 03:32.000
window, you want to be in the background.

03:32.000 --> 03:36.000
But this conflict resolution actually makes it work in

03:36.000 --> 03:38.000
even in some more selective active scenarios.

03:38.000 --> 03:42.000
You shouldn't do it, but Duff code is able to

03:42.000 --> 03:50.000
like fix all the inconsistencies eventually.

03:50.000 --> 03:54.000
It has some stay-for replication, so you don't need to

03:54.000 --> 03:58.000
start from scratch and copy over all these

03:58.000 --> 04:02.000
10,000,000 mates for a user.

04:02.000 --> 04:06.000
It really is kind of good finding the differences,

04:06.000 --> 04:08.000
and eventually running in within

04:08.000 --> 04:12.000
subsequent time for replication when for a user.

04:12.000 --> 04:18.000
So this was used as basis for the Duff code replication feature.

04:18.000 --> 04:24.000
It's on layer 7, so I don't have shared anything.

04:24.000 --> 04:30.000
So no shared storage, it works on slower,

04:30.000 --> 04:34.000
or high latency, network links.

04:34.000 --> 04:36.000
Yeah, and it's still there.

04:36.000 --> 04:38.000
It was not removed.

04:38.000 --> 04:46.000
So, actually we just need to run it somehow

04:46.000 --> 04:50.000
at the right point of time to get replication back.

04:50.000 --> 04:56.000
Looking at the replication module a little bit deeper,

04:56.000 --> 05:02.000
so we have in the end two Duff code servers.

05:02.000 --> 05:08.000
And so the grey one is just the other one in this

05:08.000 --> 05:12.000
diagram, actually both would be running pretty much the same

05:12.000 --> 05:14.000
not check here.

05:14.000 --> 05:18.000
And whenever my Duff code A gets some change, for example,

05:18.000 --> 05:22.000
a new mail arrives or a user like deletes a mail,

05:22.000 --> 05:24.000
max it, whatever could happen.

05:24.000 --> 05:28.000
There's an event sent by the internal notification

05:28.000 --> 05:32.000
system to be so-called aggregator, which is another component

05:32.000 --> 05:34.000
running inside Duff code.

05:34.000 --> 05:38.000
There's pretty much some checks with this.

05:38.000 --> 05:40.000
For example, hey did I really change something,

05:40.000 --> 05:46.000
and if so it pushes an event into a queue.

05:46.000 --> 05:50.000
On the other hand, we have the replicator, which is not doing

05:50.000 --> 05:54.000
a lot more than pulling events from this queue,

05:54.000 --> 05:56.000
and calling Duff ADM.

05:56.000 --> 06:00.000
So, it's not really like a super complicated logic.

06:00.000 --> 06:02.000
There's some more details, which I hit here.

06:02.000 --> 06:06.000
For example, we actually have a background controller, which is doing

06:06.000 --> 06:10.000
like paratics, we sync of everything,

06:10.000 --> 06:14.000
so just in case you missed some event or something else broke.

06:14.000 --> 06:18.000
We are just adding all the uses.

06:18.000 --> 06:20.000
For example, once per day to the queue,

06:20.000 --> 06:22.000
they get we synced, we are done.

06:22.000 --> 06:26.000
So, now this is gun.

06:26.000 --> 06:28.000
We have Duff code 2.4.

06:28.000 --> 06:30.000
What can we do?

06:30.000 --> 06:34.000
I guess preferred solution by Duff code

06:34.000 --> 06:38.000
is getting your credit card,

06:38.000 --> 06:42.000
and buying their professional product,

06:42.000 --> 06:44.000
a completely different architecture

06:44.000 --> 06:46.000
towards how they do HAA.

06:46.000 --> 06:50.000
There's a cloud native, whatever storage solution.

06:50.000 --> 06:54.000
We have a metadata database,

06:54.000 --> 06:56.000
which is also replicated,

06:56.000 --> 06:58.000
and statusbackers.

06:58.000 --> 07:00.000
So, they don't have this issue at all.

07:00.000 --> 07:02.000
They don't need the replication module.

07:02.000 --> 07:08.000
Well, it's a closed source, so we had first them.

07:08.000 --> 07:10.000
That's probably not what we are looking into.

07:10.000 --> 07:14.000
Also, with this cloud native storage system,

07:14.000 --> 07:20.000
with Cassandra, it's a little bit more involved in operations for sure.

07:20.000 --> 07:24.000
The officially recommended way of doing this is a shared file system.

07:24.000 --> 07:26.000
This is actually a pretty classic way,

07:26.000 --> 07:28.000
which probably a lot of uses.

07:28.000 --> 07:30.000
I actually do it.

07:30.000 --> 07:32.000
It's totally fine for Duff code.

07:32.000 --> 07:36.000
If you put the maids on some NFS server,

07:36.000 --> 07:38.000
you have two sides.

07:38.000 --> 07:40.000
You replicate stuff,

07:40.000 --> 07:42.000
and you're doing a failover needed.

07:42.000 --> 07:44.000
Works pretty nice.

07:44.000 --> 07:48.000
If data centers structure fits and everything,

07:48.000 --> 07:52.000
you are kind of bound to meet your level gear redundancies,

07:52.000 --> 08:04.000
a chance of cropping over your maids to some place that's further away.

08:04.000 --> 08:08.000
And, well, from my special case,

08:08.000 --> 08:12.000
this is not built for a high latency network links.

08:12.000 --> 08:16.000
So, this was out for me.

08:16.000 --> 08:18.000
Yeah.

08:18.000 --> 08:22.000
Patrick Chen, I hope I'm pronouncing this correct,

08:22.000 --> 08:26.000
actually did some work in,

08:26.000 --> 08:30.000
while taking this patch, which was removed,

08:30.000 --> 08:32.000
and just applying it to 2.4 again.

08:32.000 --> 08:36.000
Yeah.

08:36.000 --> 08:40.000
So, from what he reports,

08:40.000 --> 08:42.000
this was kind of fine and actually worked out pretty well.

08:42.000 --> 08:46.000
There's a minor changes between 2.3 and 2.4,

08:46.000 --> 08:50.000
which requires some adoptions of the patch.

08:50.000 --> 08:52.000
Well, yeah, Captain obvious.

08:52.000 --> 08:54.000
It's well tested.

08:54.000 --> 08:55.000
The code works.

08:55.000 --> 08:57.000
You don't have to change a configuration.

08:57.000 --> 08:59.000
It's kind of a drop-in replacement.

08:59.000 --> 09:01.000
You just take the patch binary.

09:01.000 --> 09:05.000
Throw it into the system, and you'll find.

09:05.000 --> 09:07.000
Hmm.

09:07.000 --> 09:09.000
On the long term, I'm not sure,

09:09.000 --> 09:11.000
because this requires patching the duff-cut source code.

09:11.000 --> 09:13.000
So, whenever duff-cut is changed,

09:13.000 --> 09:15.000
you have to add up the patch.

09:15.000 --> 09:19.000
When you have trouble with duff-cut,

09:19.000 --> 09:21.000
they realize as they say,

09:21.000 --> 09:24.000
yeah, fix it yourself.

09:24.000 --> 09:26.000
We are not analyzing this.

09:26.000 --> 09:29.000
So, and over time,

09:29.000 --> 09:33.000
this will definitely get more complicated in big potting.

09:33.000 --> 09:34.000
I'm pretty sure.

09:34.000 --> 09:37.000
And if duff-cut changes some more stuff,

09:37.000 --> 09:39.000
like the notification system,

09:39.000 --> 09:41.000
which is just for building plugins,

09:41.000 --> 09:44.000
then, yeah,

09:44.000 --> 09:49.000
you might end up learning this is now entirely broken.

09:49.000 --> 09:55.000
So, these things are still around.

09:56.000 --> 10:02.000
We just need something that calls duff-admdysic.

10:02.000 --> 10:04.000
Whenever it is needed,

10:04.000 --> 10:05.000
well,

10:05.000 --> 10:10.000
I'm not sure if the two guys from Heinlein are still around

10:10.000 --> 10:12.000
because they had a talk like two years ago,

10:12.000 --> 10:13.000
and in their slides,

10:13.000 --> 10:15.000
was something like, well, you could do it, crunch up.

10:15.000 --> 10:18.000
I think this was not like,

10:18.000 --> 10:22.000
really what they wanted to do,

10:22.000 --> 10:24.000
and it will not be good enough.

10:24.000 --> 10:26.000
Because we can run this every minute,

10:26.000 --> 10:28.000
but this is too much effort.

10:28.000 --> 10:30.000
We can do it once per day,

10:30.000 --> 10:32.000
and then you're listening the data from once a day.

10:32.000 --> 10:34.000
So, this is not a good thing.

10:34.000 --> 10:38.000
So, let's check out what duff-cut actually

10:38.000 --> 10:41.000
has offering offers to us.

10:41.000 --> 10:44.000
We need a notification system.

10:44.000 --> 10:48.000
So, going through the duff-cut documentation,

10:48.000 --> 10:50.000
we actually see there's a pretty nice,

10:50.000 --> 10:54.000
little documented official duff-cut event,

10:54.000 --> 10:55.000
HPI,

10:55.000 --> 10:58.000
which can send us events for pretty much.

10:58.000 --> 11:00.000
Anything running in duff-cut,

11:00.000 --> 11:02.000
also through an HTTP API,

11:02.000 --> 11:05.000
as JSON documents.

11:05.000 --> 11:08.000
Looks pretty nice.

11:08.000 --> 11:11.000
Whoever looked into this already

11:11.000 --> 11:15.000
realizes duff-cut can emit a lot of events here.

11:15.000 --> 11:18.000
So, we are definitely getting whatever we need.

11:19.000 --> 11:21.000
We need a queue.

11:21.000 --> 11:24.000
So, this is a sort of problem.

11:24.000 --> 11:27.000
We want to have a priority queue,

11:27.000 --> 11:30.000
because, like, if I receive a new mail,

11:30.000 --> 11:33.000
this is probably more important than somebody else,

11:33.000 --> 11:34.000
marking his mail as red.

11:34.000 --> 11:38.000
So, we want to sync new mail first, whatever.

11:38.000 --> 11:41.000
Red is might be an example,

11:41.000 --> 11:43.000
which is like easy to use.

11:43.000 --> 11:48.000
And, how we perform and well tested as queue backend.

11:48.000 --> 11:52.000
And, eventually, we need some controller,

11:52.000 --> 11:55.000
which is just bluing all these pieces together.

11:55.000 --> 12:01.000
So, we're taking these events on any changes that happened.

12:01.000 --> 12:04.000
Put it into the queue, pull it out again,

12:04.000 --> 12:06.000
put it against duff-ADM sync,

12:06.000 --> 12:08.000
see if it worked, otherwise,

12:08.000 --> 12:09.000
it would have been a bit of a queue,

12:09.000 --> 12:12.000
because never could be problem, whatever.

12:12.000 --> 12:16.000
Yeah, this should be some kind of lines of code.

12:16.000 --> 12:18.000
And, there we are.

12:18.000 --> 12:22.000
So, I started the development environment,

12:22.000 --> 12:24.000
and we have duff-ADM.

12:24.000 --> 12:27.000
Thanks to AI, we already have a logo.

12:27.000 --> 12:36.000
You already know that picture pretty much.

12:36.000 --> 12:39.000
So, it's kind of the same.

12:39.000 --> 12:42.000
We have duff-Code, and another duff-Code.

12:42.000 --> 12:48.000
So, now, the duff-Code is completely a separate process, or duff-Code.

12:48.000 --> 12:52.000
So, this is a small demo.

12:52.000 --> 12:59.000
We are now receiving the events through the HTTP event API.

12:59.000 --> 13:01.000
We are queueing it into redness.

13:01.000 --> 13:03.000
I get back to this later.

13:03.000 --> 13:07.000
And, well, some other replication book,

13:07.000 --> 13:10.000
or tasks, pulling these events, and, well,

13:10.000 --> 13:14.000
now we use the duff-ADM HTTP API, which also exists,

13:14.000 --> 13:22.000
to, well, get the sync running.

13:22.000 --> 13:28.000
All you need to do in duff-Code is setting up the event handler,

13:29.000 --> 13:33.000
and allow the duff-ADM HTTP connections.

13:33.000 --> 13:39.000
So, right now, the code can react on IMAP command finished,

13:39.000 --> 13:43.000
which is all the changes to IMAP,

13:43.000 --> 13:48.000
to IMAP, to IMAP, and, of course, we want new names.

13:48.000 --> 13:51.000
And, most important to me, it's unmodified duff-Code,

13:51.000 --> 13:57.000
because I don't want to read the code if something's written.

13:57.000 --> 14:01.000
They included mini redness, which is a small goal library.

14:01.000 --> 14:03.000
So, redness included.

14:03.000 --> 14:06.000
You don't even need redness to use this.

14:06.000 --> 14:08.000
It just works.

14:08.000 --> 14:12.000
And, once you connect the external redness,

14:12.000 --> 14:17.000
the entire demo is stateless.

14:17.000 --> 14:20.000
So, this both skates out.

14:20.000 --> 14:22.000
If needed for a larger setup,

14:22.000 --> 14:26.000
and, of course, you can go to really high availability setups.

14:27.000 --> 14:30.000
And, how the way it is built,

14:30.000 --> 14:34.000
actually it's totally sufficient to have one setup of this,

14:34.000 --> 14:37.000
and you can connect both your duff-Code.

14:37.000 --> 14:40.000
As the sync is bidirectional, it doesn't matter

14:40.000 --> 14:44.000
from where you trigger it.

14:44.000 --> 14:47.000
So, what do we now have?

14:47.000 --> 14:49.000
It's an external demo.

14:49.000 --> 14:51.000
It will totally not crash your duff-Code server,

14:51.000 --> 14:54.000
no matter what happens, it just can't.

14:55.000 --> 14:59.000
Otherwise, we have some bad issues with duff-Code.

14:59.000 --> 15:02.000
As mentioned standard API usage,

15:02.000 --> 15:06.000
if this is breaking to some changes in duff-Code,

15:06.000 --> 15:09.000
then a lot of other things will break, too.

15:09.000 --> 15:13.000
So, pretty much all enterprise integration will break eventually.

15:13.000 --> 15:17.000
The notification receiver right now has three-carved

15:17.000 --> 15:19.000
of IMAP commands.

15:19.000 --> 15:22.000
I was surprised that actually duff-Code replication

15:22.000 --> 15:27.000
did not catch all changes to mayboxes

15:27.000 --> 15:28.000
from in my opinion.

15:28.000 --> 15:30.000
So, if I did not get to the code wrong,

15:30.000 --> 15:34.000
for example, completely misses out on CIF changes

15:34.000 --> 15:36.000
and ACL stuff.

15:36.000 --> 15:40.000
Yeah, and of course, it breaks on mail delivery.

15:40.000 --> 15:46.000
So, it is pretty much covered by a full-interinter suite.

15:46.000 --> 15:48.000
I'm also shooting at works.

15:48.000 --> 15:53.000
And I catch all these events.

15:53.000 --> 15:55.000
Yeah, the queue I already mentioned.

15:55.000 --> 15:58.000
So, better is included, but swapable.

15:58.000 --> 16:00.000
We have a mini-redist in there.

16:00.000 --> 16:03.000
So, if you want to run it, it just works.

16:03.000 --> 16:06.000
And if you have a larger setup,

16:06.000 --> 16:11.000
you could at any time add a full-redist if required.

16:11.000 --> 16:16.000
But I assume that this is actually doing pretty well with pretty much,

16:16.000 --> 16:21.000
pretty large setups from where they did test with,

16:21.000 --> 16:24.000
with IMAP test from Duff-Code.

16:24.000 --> 16:27.000
It can handle quite a lot of changes.

16:27.000 --> 16:33.000
For observability, Duff-Wordness exposing

16:33.000 --> 16:35.000
Prometheus metrics.

16:35.000 --> 16:38.000
So, we get a pretty good insight

16:38.000 --> 16:40.000
and what's actually happening.

16:40.000 --> 16:42.000
I will add some more of these.

16:43.000 --> 16:46.000
We can see stuff like error rates.

16:46.000 --> 16:50.000
Hold on, the replication actually takes for users.

16:50.000 --> 16:52.000
The latency and stuff like this.

16:52.000 --> 16:56.000
And right now, it's available as a Duff-Code match.

16:56.000 --> 16:59.000
As this is GoCode, it's like a 15-minute megabyte,

16:59.000 --> 17:02.000
statically linked binary.

17:02.000 --> 17:05.000
It's just a matter of writing the release code.

17:05.000 --> 17:08.000
And you can also run it as a binary.

17:09.000 --> 17:11.000
As I'm running anything in Kubernetes,

17:11.000 --> 17:14.000
the first thing I built for Duff-Code is a hand shot,

17:14.000 --> 17:18.000
but it's like a simple binary.

17:18.000 --> 17:23.000
Putting this into a system to unit is probably easy.

17:23.000 --> 17:28.000
Just a very small example of the Duff-Code configuration,

17:28.000 --> 17:31.000
which I need to insert, so that's pretty much it.

17:31.000 --> 17:33.000
This is a long list.

17:33.000 --> 17:36.000
I did not fit any on this slide,

17:36.000 --> 17:39.000
but it's mostly these two config items,

17:39.000 --> 17:41.000
and we have replication back.

17:41.000 --> 17:44.000
It's available now.

17:44.000 --> 17:50.000
On GitHub, it's running end production on my mayor of this one user.

17:50.000 --> 17:54.000
I wouldn't crawl it production right now

17:54.000 --> 17:58.000
until this gets some more testing.

17:58.000 --> 18:00.000
Yeah.

18:00.000 --> 18:03.000
There's some smaller to the list.

18:03.000 --> 18:07.000
What's still missing for when I would call it production ready.

18:07.000 --> 18:11.000
I want to check if this is actually working with Duff-Code 2.3.

18:11.000 --> 18:16.000
I think it is, but I have to check out.

18:16.000 --> 18:18.000
I want to do some more load testing,

18:18.000 --> 18:20.000
so to see where some boundaries is,

18:20.000 --> 18:22.000
for example, where you need the external radius,

18:22.000 --> 18:24.000
if really required.

18:24.000 --> 18:26.000
Well, the real-world testing,

18:26.000 --> 18:32.000
so I don't operate huge main servers anymore.

18:32.000 --> 18:37.000
On the other hand, I have a very short line to my users or users,

18:37.000 --> 18:40.000
so I know when something would put break.

18:40.000 --> 18:44.000
Mostly documentation.

18:44.000 --> 18:49.000
And I need to know if this is helpful to you.

18:49.000 --> 18:53.000
If you would love to use something like this, reach out to me.

18:53.000 --> 18:56.000
I want to understand your use case,

18:56.000 --> 18:58.000
to see what's really the credit,

18:58.000 --> 19:01.000
and how we need to improve this.

19:01.000 --> 19:04.000
I'm pretty confident that this will work out

19:04.000 --> 19:08.000
if and stay around for quite some time.

19:08.000 --> 19:10.000
Do you still need prop-free?

19:10.000 --> 19:11.000
I don't know.

19:11.000 --> 19:13.000
I haven't checked it out,

19:13.000 --> 19:15.000
but it's like mostly copy-paste,

19:15.000 --> 19:18.000
and adjust the testing.

19:18.000 --> 19:21.000
Yeah, waiting for your feedback.

19:21.000 --> 19:25.000
I still think we have some time left.

19:25.000 --> 19:32.000
So I have a short live demo running offline,

19:32.000 --> 19:39.000
so I'm not required to use the wireless in here.

19:39.000 --> 19:44.000
What we see is, is it big enough for us, should I enlarge?

19:44.000 --> 19:47.000
So we have a tough cut on top left,

19:47.000 --> 19:50.000
another one on top right.

19:50.000 --> 19:53.000
Over here, we actually have the bottom dimming,

19:53.000 --> 19:56.000
and I can trigger some commands.

19:56.000 --> 19:59.000
And what's happening right now,

19:59.000 --> 20:02.000
we are having this parity sync,

20:02.000 --> 20:05.000
which is I think happening all 30 seconds right now,

20:05.000 --> 20:08.000
because I want to show something.

20:08.000 --> 20:12.000
It should realize that actually not a lot needs to be done.

20:12.000 --> 20:18.000
But over here, we actually see that the free static uses

20:18.000 --> 20:21.000
that I configured have been discovered,

20:21.000 --> 20:23.000
and looped over.

20:23.000 --> 20:28.000
So, okay, it just happened again.

20:28.000 --> 20:33.000
So, it connects to DuffCode,

20:33.000 --> 20:37.000
since the sync commands,

20:37.000 --> 20:41.000
let's see if we actually find it in here.

20:41.000 --> 20:43.000
Is this a laser? I think.

20:44.000 --> 20:50.000
I have two.

20:50.000 --> 20:53.000
No, no, no, no, no, no, no, no, no.

20:53.000 --> 20:55.000
Which one?

20:55.000 --> 20:57.000
No, no, no, no, no.

20:57.000 --> 20:59.000
Yeah, yeah, I'm just looking for the line,

20:59.000 --> 21:03.000
because it's like a hard to look at my back.

21:03.000 --> 21:06.000
I think it's this one.

21:06.000 --> 21:09.000
This is where we receive the message,

21:09.000 --> 21:16.000
and on the right, we should be able to observe.

21:16.000 --> 21:20.000
Yeah, so this is like the DuffADIM connection

21:20.000 --> 21:22.000
at a decent connection happening.

21:22.000 --> 21:26.000
Otherwise, if I actually trigger something

21:26.000 --> 21:29.000
like creating a mailbox,

21:29.000 --> 21:32.000
this is from the end to end just with,

21:32.000 --> 21:37.000
we see how we got the message

21:37.000 --> 21:40.000
for the user create.

21:40.000 --> 21:44.000
Well, we sent this in command

21:44.000 --> 21:46.000
and on the right side,

21:46.000 --> 21:49.000
the mailbox was transmitted again.

21:49.000 --> 21:52.000
Yeah, that's pretty much all I had.

21:52.000 --> 21:54.000
If there's any questions left,

21:54.000 --> 21:57.000
I'm also around for the entire day, I'm leaving.

21:57.000 --> 22:07.000
So can you run multiple of the instances of DuffADIM at the same time?

22:07.000 --> 22:09.000
Yes, you can.

22:09.000 --> 22:12.000
There's actually two reasons for this.

22:12.000 --> 22:15.000
One is they are pulling from the same radius.

22:15.000 --> 22:20.000
Can you run multiple of the instances of DuffADIM at the same time?

22:20.000 --> 22:22.000
Yes, you can.

22:22.000 --> 22:25.000
There's actually two reasons for this.

22:25.000 --> 22:28.000
They are pulling from the same radius queue.

22:28.000 --> 22:31.000
So this is the assumption you actually share in one radius

22:31.000 --> 22:36.000
and say you will pull out once and work on it.

22:36.000 --> 22:38.000
This also allows scaling out.

22:38.000 --> 22:42.000
The other thing is DuffADIM actually takes care of

22:42.000 --> 22:44.000
locking for a user.

22:44.000 --> 22:48.000
So if you do it manually, there's a flag

22:48.000 --> 22:53.000
which allows you to lock each user during synchronization

22:53.000 --> 22:59.000
and then DuffADIM will wait to run the other instance.

22:59.000 --> 23:04.000
Using this way, this actually even should work in parallel with DuffADIM

23:04.000 --> 23:07.000
to point three's replication code.

23:07.000 --> 23:10.000
Because from how I read the code, it's also setting the lock.

23:10.000 --> 23:14.000
So you have, you even do have for my questions.

23:14.000 --> 23:21.000
It's very interesting.

23:21.000 --> 23:26.000
And when I was reading and looking at it, it's great.

23:26.000 --> 23:29.000
I would just use it for different use cases

23:29.000 --> 23:33.000
that replication actually, you know, like it's like in the name,

23:33.000 --> 23:37.000
like DuffADIM can imagine that the actions you take out of the

23:37.000 --> 23:41.000
once you have collected all those events could be all sort of different

23:41.000 --> 23:45.000
use cases, especially if you have telemetry.

23:45.000 --> 23:49.000
It can also extend to, like, not just replication.

23:49.000 --> 23:50.000
Like a foundation.

23:50.000 --> 23:51.000
Okay.

23:51.000 --> 23:52.000
Other use cases.

23:52.000 --> 23:56.000
So the question was about, well, this is about replication,

23:56.000 --> 24:00.000
but you have a lot of other ideas like doing some telemetry stuff.

24:00.000 --> 24:05.000
Actually, using the same event subsystem,

24:05.000 --> 24:09.000
DuffADIM, at least 2.4, I'm not sure about the other ones,

24:09.000 --> 24:12.000
actually has built in telemetry exporters.

24:12.000 --> 24:15.000
So you can pretty much use the same events without an external

24:15.000 --> 24:18.000
demand to have some counters and everything in a premises

24:18.000 --> 24:19.000
compatible fashion.

24:19.000 --> 24:24.000
So it's built in already, you don't need anything extra.

24:24.000 --> 24:25.000
All right.

24:25.000 --> 24:28.000
Any questions?

24:28.000 --> 24:29.000
Everyone.

24:29.000 --> 24:30.000
All right.

24:30.000 --> 24:33.000
We're going to have a three-fold replication.

24:33.000 --> 24:36.000
Yeah, yeah.

24:36.000 --> 24:47.000
So DuffADIM is still built into DuffADIM 2.4, which is the free one.

24:47.000 --> 24:52.000
So you don't need to buy the perversion, which is like a 3.0 release.

24:52.000 --> 25:00.000
This is bringing the removed replication code back to DuffADIM 2.4

25:00.000 --> 25:02.000
in the open source version.

25:02.000 --> 25:06.000
So this is fully working with open source.

25:06.000 --> 25:10.000
I have a three-fold replication code.

25:10.000 --> 25:12.000
Ah, a three.

25:12.000 --> 25:17.000
I haven't heard of, this is like a supported way of operation.

25:17.000 --> 25:23.000
I guess it would actually work, but I don't think a lot of people

25:23.000 --> 25:28.000
run it this way and you might run into these weird edge cases

25:28.000 --> 25:29.000
that might exist.

25:29.000 --> 25:32.000
I wouldn't do it personally.

25:32.000 --> 25:35.000
Yeah, I assume.

25:35.000 --> 25:38.000
Okay.

25:38.000 --> 25:42.000
So, thank you.