См. Документацию для ServerApp
типа . Как только действие IO завершается, базовый сокет закрывается. Итак, каждый из ваших первых трех клиентов принимает соединение, сохраняет соединение в state
, а затем завершает работу, закрывая соединение. Только четвертый клиент сохраняет свое соединение открытым, и он не может делать ничего полезного с остальными тремя соединениями, которые теперь закрыты.
Если вы заменили последнюю строку на:
Nothing -> do
putMVar state cs'
threadDelay (10^9) -- wait a while
тогда это, вероятно, соединит всех четырех клиентов.
Чтобы исправить это «по-настоящему», вы можете заставить первые три соединения ждать вечно, а затем организовать четвертый поток, чтобы убить их, когда игра закончится. .
Однако я не уверен, что это правильная архитектура. Вместо того, чтобы только четвертый поток соединений работал и опрашивал все четыре соединения, вы, вероятно, захотите, чтобы каждый поток соединений вводил al oop для обработки входящих сообщений от своего клиента. Эти потоки могут изменять общее игровое состояние и / или напрямую транслировать сообщения другому клиенту (например, пример программы "chat" в документации websockets
) или помещать в очередь входящие сообщения для обработки отдельного потока игры.