А что? фз... я еще не дожил спелчекером код проверять =) Вроде обычно более менее грамотно пишу... ну так на первый взгляд никаких ошибок не обнаружил? Что не так? =)

Название класса.

Ааааа.... млин, ну, опечатался, ща поправлю =)

Олег, любые конекшины впринципе не могут являться сингтонами. ведь их может быть много одинаковых, но на разные домены, или сразными настройками. в общем завтра когда руководство скажет тебе, что по новому сокету тебе надо получаться постояные коментарии к первому потоку, ты подумаешь, а нафига я сделал синглтон?

не, не скажет, моя флешка - часть большого проекта, в котором это взаимодействие описано. По техническим причинам она не сможет коннектится к >2 сокетам. Так устроена остальная часть, которая от меня не зависит. Это одно из соображений оптимизации, и оно очень важно в моем случае. Т.е. флешка запускается локально на сервере (не пользователем, а таском), но тредов запустивших флешку может быть много (т.е. будет запущено много копий флешки). Так что запустить +1 сокет для каждой копии (каждого нового треда) - на это никто не пойдет...

wvxvw, скажи, а методы connect и close могут вызывать кто угодно и где угодно?
синглтон в твоём случаи должен ограничить разработчика от нежелательный действий с соединением. твоё соединение теоретически одно. заметь только теоретически, но закрыть его или открыть может кто угодно и откуда угодно. нафига тут синглтон? :)

Это не полное содержание класса =) он на самом деле на много больше, connect и close никто не может вызвать, просто в примере это не описано.

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

дело не в копиях :) дело в том, что завтра надо будет второй такой же класс. чё делать? писать ещё один синглтон?

Вероятность необходимости еще одного такого же класса, с таким же функционалом практически равна 0... т.е. предположим, что в ближайший год производительность серверов в среднем увеличится в 2 раза (уже как-то стремно =), ну ок, и мы решим задействовать открывшийся ресурс для того, чтобы прицепить туда еще 1 сокет (ну, не так уж много это и занимает, в конце концов =), но, что он будет делать? Сокет-отправитель уже есть, сокет-получатель - тоже. Приложение должно выполнять 2 операции: получать и посылать. Чего бы еще ему такое придумать? - Я вижу вариант только такой: в рандомально выбраное время откывать дверцу сидирома и загробным голосом произносить "my preeeeecioussssss.....". :D

Олег :) у нас в проектах обычно минимум 2 сокета. хотя можно конечно загрузить всё в один. а ещё можно использовать один сервер, где надёжнее использовать 4.

ты мне вот скажи зачем там нужен синглтон? да хоть 100 отправителей :) если говорить на уровне проектирования, то сокетов быть не должно в принципе. все твои "отправители" должны работать с неким абстрактным интерфейсом имеющим пару методов. как пример метод call у NetConnection. что происходит внутри должно быть чёрным ящиком. и откуда берётся тоже. писать во всех твоих отправителях RegistrationManagerProxy.getInstance(); меня бы задолбало, а сохронять ссылку нельзя, так как ты не можешь знать, что происходит в getInstance(). вдруг там нечто важное происходит? в общем это не тру-путь.