Это уже есть и для этого введено понятие ClientID. CurClientID на момент всех событий всегда содержит ID клиента, от которого это событие произошло.
Здесь нет ничего необычного - браузер тоже экономит соединения. Кроме того, для протокола HTTP это штатная возможность, обеспечивается заголовком Connection: Keep-alive. Этот заголовок указывает серверу не разрывать соединение после ответа. Вероятно, это же должен делать клиент, если получит такой заголовок от сервера. Ну и разрыв соединения при Connection: close.

Ты неизбежно столкнешься с тем, что данные от клиента приходят порциями и в случае сервера, вперемешку от разных клиентов. Схему нужно строить таким образом, чтобы сохранять изолированное "состояние" каждого клиента. То-есть, когда данные приходят частями (для примера, 1 соединение), тебе по-любому нужно накапливать некоторое количество данных и после каждого фрагмента анализировать накопленные данные с целью получить полные заголовки запроса (накапливать до получения двух переводов строки). Если запрос GET, ты можешь начинать отправлять ответ. Если POST - смотришь Content-Length и продолжаешь накапливать данные, пока не получишь эту длину. Отправляешь ответ и снова переключаешься на ожидание двух переводов строки. Сделать это можно, например, динамическим мультиком:
- подключился клиент - добавили копию схемы в мультик, в схеме сохранили CurClientID для дальнейшего сопоставления
- отключился клиент - удалили схему
- получили любое другое событие - взяли CurClientID, в цикле перебрали все копии схемы в мультике, по нему нашли нужную и сделали её текущей, передали в нее событие на обработку.
- внутри каждой схемы в мультике и выполнять обработку привязанного соединения.