Одно сокет подключение на несколько классов
 

До этого никогда не создавал приложений на сокетах, но как они работают в теории представляю. И вот вроде дорос до XMLсокет приложения, сел набрасывать структуру приложения клиента и возник вопрос: Предположим имеется родительский класс некой систем, в данной системе несколько детей с кучей свойств у каждого. И вот таких систем в БД может быть несколько. Логичным было бы подгружать каждые свойства подсистемы по мере необходимости, но подумав как это будет пришел в замешательство: Передавать ссылку на xmlsocket каждому ребёнку и от него в нужное время делать запрос, учитывая то что главная система может пользоваться сокетом на данный момент... ерунда выходит... тем более ответы на запросы получает сокет который слушает только родительская система, и как она будет раскидывать ответы сервера по детям, не подписывать же детей на прослушку сервера и потом выдирать из всех ответов свой? в приницпе реально через методы родительской системы, но стоит ли того.... к тому же каждый юнит системы может вносить изменения в бд, опять же: делать это через ссылку на сокет или через методы родительской системы. вообщем путаница в голове полная, объясните кому не лень, как вернее?

Добавлено через 2 минуты
http не предлагать

Добавлено через 2 минуты
И ещё вопрос, нормально ли будет работать несколько сокет подключений клиент/сервер на разные порты?

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

а как ответы распределяете? класс сокета сам раскидывает через методы детей?

Нет, он вообще никаких методов не дергает. Он только рассылает события, а классы, которым что-то от него нужно регистрируются на эти события, и уже по доставке события, дергают его геттеры. Да и детей у него нет, он расширяет EventDispatcher

в моём случае это не подойдёт... геттер должен будет отдать xml тип, обработав его под конкретного дитя той структуры в которую он посылает событие... чё-то не то.... разные структуры приложений

Добавлено через 7 минут
в моём случае "система" может меняться в реалтайм и могут меняться все её дети в реалтайм.... дети не есть расширением родителя, они просто в неё входят и представляют отдельные классы с множеством различных свойств. Со структурой сервера проблем не возникает, потоки решают всё, а вот клиент...

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

С этим тоже не должно быть проблем – шлете сообщение на клиент о создании нового потомка и кода для него.

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

Это плохо вообще.
По хорошему дети не должны знать ни о протоколе ни о том, что есть какой-то сервер которому можно что-то послать.
За всем следит единый (хотя не обязательно единый) ServerManager который может подключать разные парсеры преобразовывающие внутренние объекты в нужный протокол и обратно.
Часто одни и те же данные могут отправляться-приниматься по разному..
например у юзера закрыты дефолтные порты, пробуем установить связь по другому порту, если нет пробуем http - connect если и он не проходие - создаём http-polling соединение..
Классам предметной области об этом знать не надо.
Пришло сообщение с сервера. Менеджер его принял - подключенные парсеры его обраьботали преобразовали в нужный вид - далее предали главному контроллеру приложения.
Контроллер уже решает что с ним делать, но он работает не с каким то xml, а с уже сериализованными данными.
То же самое и обратно. Модуль послал сообщение, контроллер его обработал передал сервер-менеджеру, менеджер через парсер десериализовал и отправил по нужному протоколу на сервер.
Всё.
Если вы работаете в режиме RPC - то тут ситуайия немного сложнее и нужно вводить идентификаторы запросов, организовавать очереди и т.п. Но всё равно модуль будет отправлять типизированный в AS класс запроса в котором может быть ссылка кна колбэк, в этот колбэк и прийдёт уже стипизированный ответ.
Вот немножко про сокеты.

Котяра, предпологается внушительное количество свойст у адресатов(классов назначения), какой смысл мне из xml все сериализировать, предположим в тот же массив и потом передавать адресатам, если можно передавать уже обработанный xml? Или предположим создать класс единный для всех адресатов в котором будет xml обработчик(и другие основы), а от него расширять всех детей. Нюанс в том, что ответ от сервера, как я планирую, будет довольно внушительный по объёмам и предназначаться для несколька десятка классов. Как Вы писали, server manager будет его обрабатывать на мелкие xml для конкретных классов и дергать методы соответствующих классов с параметром xml. Можно конечно сделать чтобы он его разбивал на не маленькие xml а на массивы и передавал методу массив, но в чём разница?

За ссылку спасибо, но я не так мало понимаю в сокетах чтобы она мне помогла, перечитал куда более серьёзные руководства

Разница в том, что классам предметной области не надо знать ни про какой xml, если им нужен массив - они должны получить массив.
Протокол поменялся - поменяли только классы парсеров - предметная область остаётся неизменной. И наоборот - решили вместо массива объектов с аттрибутами сделать хэш объектов по id - тоже меняем только парсер (ну и сам класс предметной области гду нужен этот хэш) - протокол оставляем неизменным.
Я это говорю не просто так, а с позиции своего опыта - во первых, протоколы меняются всегда, даже если изначально не предполагалось их менять, а во вторых, незачем загромождать предметные классы парсингом. В них должна быть описана только нужная логика.