День добрый!
Есть сервер и куча клиентов. Которым не просто надо взаимодействовать, а взаимодействовать одновременно(ну почти  ).
Ну и собственно 2 вопросса:
1. А правильно ли изначально много (в моём понимании >1000) клиентов делать через сокет? Нееее не вдруг есть другие варианты...

2. Что-то у меня такая подозряна что одновременно сервер не вынесет столько сокетов... Где-то я слышал что можно не держать их(сокеты) постоянно вот только если их не держать постоянно не слошком ли дорого будет создавать ЦЕЛЫЙ сокет для одного сообщения? И вообще где можно про это почитать а то серч как-то немомогает  

Зарание спасибо!

ЗЫ Как пример может служить схема чата(много клиентов и большой поток информации), но ко всему этому на сервере идут большие вычисления...
ЗЗЫ Был бы очень признателен еслиб вы поделились опытом реально работающих подобных системну... хотяб сколько реально коннектов одновременно и что за железо

Это сообщение отредактировал(а) KOp4iK - 31.8.2006, 17:58

1. А как иначе, если взаимодействие через сеть и все клиенты соединяются с разных компьютеров?

2. Количество соединений не так критично, как количество данных передаваемых через них.

яж говорю 



т.е. если 1000 ... 2000 человек будут весеть онлайн и посылать/получать раз в минуту по байтику то всё будет летать?!?!? Если честно то слабо вериться ... не ну я всё понимаю но тыща - две коннектов ЭТОЖЕ МНОГО!!!  

И тогда сразу вопрос напрашиваеться: А что можно сделать если и клиентов много и данных все посылают много???

Попробуй.


Оптимизировать 

А как пробовать-то на одной машине?!??!!? Это читерство!!! А на разных - где я столько возьму?!?!?



только КАК? Вы не подумайте ях не прошу за меня код писать ... просто никаких мыслей на тему оптимизирования нет 

По-моему в случае чата 1000 - 2000 клиентов не критично, а вот если они файло тянуть будут или заливать(еще и одновременно..   ), тогда конечно что-то надо делать с оптимизацией, но это уже от задачи зависит...

анекдот помните? "Что же вы Родион старушку за десять копеек? Не скажите, десять старушек - уже рубль." Самая простая оптимизация - добавить сервер.   

нее так всё брутально не будет... говорюж: чат + вычисления


как учит нас теория при сложности алгоритма O^3 - добавлялка сломаеться... да и хоцца как раз узнать при одной среднестатистической машине(3Ghz 1GB) что можно ожидать!  

Достаточно один сервер и 2-3 машины которые будут имитировать клиентов.


Будут проблемы с производительностью, будешь оптимизировать. И почитай O'Reilly - Java Network Programming.

Имхо лучше в данном варианте гуглить в сторону широковещательных и многоадресных передач. broadcast и multicast.  






Более чем наверняка зависит от ОСи. ЯВА скорее использует возможности ОС, чем читает/пишет с сетевой платы.


Кстати, в моём линуксе кол-во одновременно открытых файлов(вкл. сокеты) не превышает тысячу с лишним. А дальше идёт ой, который преобразуется в яве в TooManyFilesOpenedException, или около того.





Это сообщение отредактировал(а) Mayk - 4.9.2006, 15:53

1. в интернете широковещательные запросы не пройдут
2. UDP не гарантирует доставку
3. в какдом пакете придется передавать информацию, для аутентификации клиента
4. SSL к ним не прикрутишь

Как думаешь почему ни одна IM служба не использует UDP, а только TCP/IP?

За книгу пасиб однозначный!!! Будем искать и читать!!!

И всётаки не хоцца закрывать тему вдруг кто-нить ещё чё-нить придумает   

Это сообщение отредактировал(а) KOp4iK - 4.9.2006, 20:23

1 решается использованием многоадресной передачей AFAICS
2-4 лежат на программере.

А теперь представим что нам надо передать 1 мегабайт информации каждому клиенту.
(1 мегабайт в х
не такая редкая и большая цифра.)
Всего клиентов 1000. 1000 * 1024 ~= гигабайт исходящего траффика. 



Вот ещё вопрос - что быстрее и надежней - разобраться с UDP и multicast'ом и отпарвить пусть даже 10 метров при плохой связи, или отправить 1 гиг в сеть при идеальной связи по TCP?


Перебор. Zephyr is a UDP-based protocol.

ТАК по ходу топ начинаеться скатываться в оффтоп... Сорри но просто не заметил сразу Всем клиентам надо посылать разные данные... т.е. иногда данные будут одинаковые ... но в основном разные!!!

Копчик, судя по всему вы хотите удивить мир новой сетевой игрой.    А оффтоп от абстрактности вопросов . Виндоуз позволяет адресоваться приблизительно к 65000 портов. Приблизительно первая тысяча зарезервирована за системными портами. Значит остается 64 тыс. портов. Однако машина врядли сможет обслужить 64000 сокетов. А сколько сможет - зависит много от чего.

Это сообщение отредактировал(а) COVD2 - 5.9.2006, 17:14

Создадим себе трудности, чтобы потом их героически преодолеть.
Проблемы с производительностью могут и не возникнуть, а вот гемморой с программированием гарантировано будет.

Хм... А зачем куча сокетов... Одного хватит, а вот потоков будет куча. Насколько мне не изменяет память в рамках Java, классическая архитектура сервера выглядит так:


На сервере придётся открыть на вход тысячный порт, а клиенты будут делать исходящие коннекты по этому самому порту.





Это сообщение отредактировал(а) val - 7.9.2006, 16:06

val тот код который ты привел создает новое соединение (и соответсвенно новый клиентский сокет), на каждом вызове accept().

И займёт новый порт, выбранный и выделенный абсолютно прозрачно для данного  кода

Это сообщение отредактировал(а) chief39 - 7.9.2006, 17:40

Согласен. 

смотри в стороnу java nio.

посмотрел...    но этож стандартные Java классы... А у меня вопрос по архитектуре...

Тебе надо написать сервер состоящий из одного Thread'a.И не надо не каких супер ви4еслителных мощностей.Ты просто их поставиш в о4ередь.

неее в очередь это некошерно!!! тогда одно сообщение будет тормозить все остальные!

Как я понял, он просто призывает не создавать по треду на каждого клиента. Создается пара тредов которые читают данные от клиенов, и кладут их в очередь на обработку. Пара тредов которые обрабатывают данные от клиентов и помещают результаты в очередь. И еще пара тредов рассылает данные клиентам, или даже первые два нагрузить подобной работой.
Просто для этого требуется неблокируемое чтение данных, но это в в io есть nio тут не обязательно.

Ну тогда 2 варианта решения.
1. Супер PC
2. O4ередь

Да коне4но код можно пошерстить на производителность.Но я думаю , 4то это повысет не зна4ительно её повысет.

С чего такие странные выводы?

 Если можно поподробнее или  или как это правильно называеться... чтоб для поиска

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

Это сообщение отредактировал(а) COVD - 26.9.2006, 14:49

NIO рулит 

я делал чтото подобное правда трафик был маленький и вычисления тоже, если не ошибаюсь на примерно 1000 потоков сьедало около 100м оперативки

1000 потоков - это не только память, но и время, расходуемое на переключение потоков. А NIO позволяет обойтись одним.

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

И еще одно печальное обстоятельство. Если сервер обслуживает клиентов через интернет, то найдутся клиенты, выходящие в интернет через прокси сервер. В крупных компаниях доступ в интернет организован как правило через прокси сервер. Пользователи из таких компаний представляют повышенный интерес для сервиса ("Нашими услугами пользуется Кока-Кола!"  ) , но и доставляют много хлопот.  Как правило, они не могут создать прямое сокетное соединение. Единственным разрешенным протоколом связи для них является HTTP соединение на 80 порт. Поэтому кроме TCP/IP сокетного соединения (с НИО или без) необходимо иметь и канал связи по протоколу HTTP. А это несколько другая концепция. Конечно, есть попытки прикрутить НИО к сервлетам ( http://weblogs.java.net/blog/jfarcand/arch...ly_an_http.html ), но все же это не совсем распространенная практика. 

Поэтому сказать, что дело NIO живет и побеждает, можно с определенной натяжкой.