Странно это для клиентов будет.
Я посылаю запрос А передает С 10 бочек апельсинов.
Потом посылаю запрос С передает Д 5 бочек апельсинов.
Мне приходит ответ, что у С ничего нет. И я долго чешу репу, куда же они делись. Ведь он должен был от А получить 10.

Корректнее выполнять операции с участием С, когда остальные операции с его участием уже выполнились.

Мы уже провели 100500 тысяч тестов и выяснили, что массивы чрезвычайно медленные. Для buffer идеальный кандидат Set(). Для pool — Map(). А так для обоих случаев может быть кандидатом и Object() — но он не всегда себя показывает достойно в тестах.

Т.к. в buffer (список обрабатываемых участников) хранятся только имена участников, то Set отлично подходит для этой задачи — как в реализации, так и в скорости.

В pool (очередь участников, которые не смогли попасть в buffer) у нас уже хранятся сами операции, состоящие из 2-х имен участников и действии, которые первый участник хочет сделать для второго. Т.к. Set может хранить только уникальные значения без ключей, то для pool подходит либо Map, либо Object.

:haha: Отправлять запрос может только сам участник инициатор операции — никто за него это сделать не сможет.

Если вы знаете, что вам участник А должен передать 10 бочек апельсинов, то очевидно же что вы не будете пытаться передать участнику Д 5 бочек, пока не убедитесь, что на вашем складе больше или равно 5 бочек.

А что для операции <A op B> в этом случае для Map является ключом, а что значением?
И как последовательно (или еще как) просматривать Map, не превращая его в массив?

Как можно просматривать этот пул? Взять одну операцию, посмотреть, может ли она быть выполнена, взять следующую и т.д.?

Что же в этом корректного? Исходя из такой логики операции вообще смогут никогда не выполниться, т.к. все будут постоянно друг друга ждать.

Нет не будут ждать. Как только очередная операция выполняется ее члены удаляются из буфера и просматривается очередь, на предмет того, какая операция может быть выполнена. Первая, которая может - выполняется. Можно и дальше просматривать, что бы послать на выполнение все, которые в этот момент могут быть выполнены. Но это гарантирует, что операции, например с участником А будут выполняться строго в последовательности, как они пришли.

Кстати да, неоднократно этот вопрос вставал как это делать. И сейчас пришла мысль — а может вообще отказаться от этого пула? Сейчас пришла такая мысль:

1. Если участников операции нет в buffer - добавляем в него и выполняем.
2. Если хотя бы один из участников есть в buffer, то делаем setTimeout() и пробуем до тех пор, пока не получится как в п.1

Причем это можно сделать как на стороне сервера, так и на стороне клиента.

Не самое лучшее, на мой взгляд, решение.
А пул - простой список.
Пришедшие операции добавляются в конец.
Есть два события: 1 - операция добавилась 2 - какая то операция выполнилась.
По каждому из этих событий мы просматриваем очередь от начала до конца. Если какая то операция может быть выполнена, то она отправляется на выполнение.

Опять же все завит от условий. Если в пуле десятки записей, то и массив с операциями push и splice будет прекрасно работать. Это внутренние хорошо оптимизированные операции.

Вообще pool хз откуда появился. Первоначально была задача решить реализацию buffer. И сейчас я понимаю, что этот pool просто не нужен. Это же не очередь за квартирой в Москве или какая-то доставка пиццы, где важно хранить очерёдность (потому что это занимает продолжительное время).

В 99% случаев для каждого участника операции будет свободное место в buffer. А если и не будет - то оно очень скоро освободится.