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

До этого никогда не создавал приложений на сокетах, но как они работают в теории представляю. И вот вроде дорос до 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 - тоже меняем только парсер (ну и сам класс предметной области гду нужен этот хэш) - протокол оставляем неизменным.
Я это говорю не просто так, а с позиции своего опыта - во первых, протоколы меняются всегда, даже если изначально не предполагалось их менять, а во вторых, незачем загромождать предметные классы парсингом. В них должна быть описана только нужная логика.

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

Многое переосмыслил, огромное спасибо за советы!

Ну да, основы MVC базируются на простой логике и оптимальному подходу к созданию архитектуры проекта. Поэтому модуль работы с сокетом должен быть черным ящиком для любого другого класса. Более того, основываясь на событийной модели флеша, даже родительскому классу не обязательно иметь ссылку для дерганья сокета - создал, подписался и гоняй событи туда-сюда.
Меня, правда, слегка удивляет выбор xml-сокета, когда есть бинарные, когда можно работать с amf и использовать преимущества rpc и remote object - автоматически вопросы парсинга отпадут, скорость выше, объемы меньше.

Зачем выдумывать велосипед? Для использования бинарного сокета необходимо создавать парсер, когда для xml существуют готовые инструменты. Что касается размеров, то xml разметка занимает максимум процентов 5 от общего объема и выиграть на этом трудно. За что-то же он получил популярность? А что касается rpc и remote object, то тут уже играет роль реализация структуры приложения, не забывайте что мы пишем на AS3, а не cpp.

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

blaze это НЕ сокет. это http