LastLeader, вижу, Вам понравилась упаковка в поток. В случае с большим количеством однотипных данных это проще и надёжнее, чем делать перебор и слать по отдельным входам шифратора. Шифратор (ChanelToIndex) я приводил в пример асинхронной последовательно-поочерёдной связи, когда на любой вход в неизвестный момент может поступить одно событие с данными в потоке. Если у Вас фиксированное число параметров при каждой передаче,то шифрациюдешифрацию вообще можно убрать, пример "параллельной", синхронной связи с передачей разных данных одним пакетом после объединения, количество и типы данных заданы жёстко:

code_23459.txt
------------ Дoбавленo в 08.55:
Я тут вспомнил, что у Вас при выборе сервера применяется сразу несколько элементов PING. Мне кажется, в этом нет необходимости, больше недостатков. Во-первых, пинги расставлены у вас в основном потоке (main thread) приложения, и оно может заметно "подвисать" на таймауты при плохой связи. Во-вторых, пинг (протокол ICMP) может (не редкость) быть заблокированутрачен на NAT, маршрутизаторах, файерволах и разных проактивных защитах. Ну, и в третьих, TCP_client уже имеет события onError (не реализовано) onConnect и onDisconnect, позволяющие сделать выводы о пропадании связи с сервером и переключиться на следующий по списку. Ещё одним плюсом onDisconnect является оперативная реакция на пропаданиеразрыв связи, в отличие от однократного PING, который был у Вас в схеме. Даже если PING вызывать регулярно, при плохой связи он будет лишь подтормаживать приложение, пока делает вывод о доступности сервера. А при особо плохой связи, получив превышение таймаута и не дождавшись ответа, который порой идёт ОЧЕНЬ долго (классический пример - некачественный региональный "мобильный интернет"), он сделает выводы неверно и программа по Вашей схеме вообще уйдёт пинговать альтернативный сервер в ИнтернетLAN, то есть потратит некоторое время не работая. Удачи в сетевом программировании)