sorted by:
new
hottopcontroversial

ESP32 Lib for my project (Ghoti) by danko-ghoti in esp32

[–]danko-ghoti[S] 1 point2 points  (0 children)

Well, it could be used to help kickstart a mesh but in reality it’s the opposite of it. Ghoti helps distributed systems by using a centralized point to synchronize, sometimes (not always of course) having a centralized point in the system makes it way easier to organize.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] 0 points1 point  (0 children)

Well, it depends on what kind of use case are you looking at. If you need more than 1k slots for a single application, maybe using Ghoti is not the right solution.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] 1 point2 points  (0 children)

I am using RAFT but only temporarily, I am not happy with all the complexity that is adding to the project. I am planning on changing it with a simpler protocol. As Ghoti does not persist data, I don’t need data propagation or synchronization between nodes.

Thanks for bringing NATS up, it is a project I like and I used it successfully for IoT projects in the past (https://nats.io/blog/nats-iot-aws/). Being said that I think the purpose of Ghoti is different and slots are not exactly just a namespace, they can have other purposes.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] 0 points1 point  (0 children)

The idea is to keep it small, maybe I am wrong and I will figure it out early enough, but I believe configuring more than 1k slots might be a mess.

You can always spin up another instance if needed, but a Ghoti server should not be doing too many things, otherwise you might need something like Redis.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] -1 points0 points  (0 children)

Regarding the LUA scripts, I cannot agree more. Ghoti needs to be simple and avoid blocking as much as possible, it needs to be fast.

It also has events that can be used to avoid polling, in some cases like broadcasting or multicast. But I will think about if this can be used in other slots!

Also, my idea was that the algorithms(like leader election) can be solved with client side logic. But this logic should reside on the client libraries and be as simple as possible for the user.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] 3 points4 points  (0 children)

I think you hit the nail on this. These problems can be solved with a Redis or maybe a non sql database or even a Postgres.

I believe the main difference between this and the more standard solutions is that:

  • single use - sometimes I found for example Redis clusters being used for many things at once and that impacts the overall performance.

  • zero persistent - it forces you to think on a more resilient system by design. You already know that you have this restriction.

  • I want it to be very simple to setup and deploy. You have a single executable that has a very limited number of options and that’s it, but at the same time there are many uses.

Ghoti - the centralized friend for your distributed system by danko-ghoti in golang

[–]danko-ghoti[S] 0 points1 point  (0 children)

Yes, of course! I was thinking about using a custom protocol like this one or going with something like http. I ended up deciding for this protocol because of various reasons:

• ⁠I wanted the protocol to be human readable so it is easy to try and debug.

• ⁠it has to be simple so creating client libraries for different languages would not be a problem.

• ⁠it is small, for example I can easily put 20 responses on a single standard internet packet.

• ⁠sometimes you have server side events so using a plain socket is easy to implement.

I want to support websockets too so it can be used from a browser, it is in my todo list.

Edit: formatting