Организация клиент-серверного приложения

[ror13]

Необходимо написать многопользовательское клиент-серверное приложение без отдельного сервера, целостность данных важна.
Чтоб конкретизировать пусть это будет чат.
Выбрал winsock tcp.
Как я понял каждое приложение должно слушать порт (тоесть быть сервером) и естественно инициализировать соединение (клиент). С этим всё понятно а вот как лучше поступить дальше вопрос.., у меня есть несколько вариантов:
1. Запуск приложения, создание сервера, получаем компьютеры в сети, их ip и наличие открытого порта для общения, если порт присутствует посылаем запрос создания подключения и устанавливаем его, и так со всеми. Тоесть каждый участник такой сети получается как сервер, ладно при 10 потоках вроде должно быть всё норм а в от если их будет 200… в общем бредово...
2. Запуск приложения, создание сервера, получаем компьютеры в сети, их ip и наличие открытого порта для общения, если есть сохраняем ip себе. Далее если я захочу отправить сообщение то соединяюсь с каждым из своего списка айпишником и отправляю ему сообщение после чего соединение разрываю(удаляю поток). Эта идея кажется более рациональной, но на сколько медленней это будет(ну и естественно надо периодически обновлять список ip)

Мб я совсем не туда капаю и есть какие-нибудь альтернативы?..

[nxnx]

клиент-серверное приложение без отдельного сервера

это как? кто сервером а кто клиентом будет?

[ror13]

я сверху и написал как реализовать две похожие идеи "без сервера", естественно без сервера это образно, тоесть каждое приложение может быть сервером... я уверен что так работать будет вопрос на сколько будет тормозить ... поэтом привёл на мой взгляд два очевидных решения, вопрос в том существует ли 3 вариант? и какой из моих 2-ух более рациональный?
вот нарисовал 1-ый вариант:

1 - по серверной свзяи сконекшен с 2-6
2- по серверной свзяи сконекшен с 3-6, а с 1 как клиент
и тд..
6 как клиент с 1-5

Второй вариант нарисовать сложно… но похоже, для второго варианта мы связь не держим, тоесть для отправки сообщение 6 создаёт коннект с 1-5 передаёт и закрывает коннект.
И ещё раз повторюсь, я склонен ко второму вопрос в том какова будет потеря времени и стабильности передачи.

[veniside]

> Мб я совсем не туда капаю и есть какие-нибудь альтернативы?

если проект будет работать только в локалке, можно мультикастом рассылать сообщения.

если планируется работа и в тырнете, то забей сразу. Не будут сервера работать на каждом клиенте. Т.е. процентов 90% машин будут только клиентами. Фактически, получится то же самое, что и с выделенным сервером, только возни на порядок больше. Поэтому, имхо, если нужна работа проекта в тырнете, сразу определись, что вот эта машина будет сервером, а остальные только клиентами. Ну на крайний случай можно поднять несколько серверов и пробить их список у всех клиентов. Только смысла в этом нет особого. Так делают, если нагрузка на сервер большая, чтобы разбросать её на несколько машин. Не думаю, что чат настолько загрузит сеть )

[ror13]

я сообразил что мне надо ещё когда картинку рисовал... уж больно она мне показалась знакомой... а получается то обычная p2p сеть... veniside благодаря за ответ на назревший ещё 1 вопрос об инет реализации, тоесть если в инет, то без сервера синхронизации, как например у битторент, никак...
и остался ещё 1 нубский вопрос.
Что-то нигде не увидел на него ответа:
Когда я создаю подключение отправляю данные и закрываю подключение, на сколько медленней это будет работать относительно обмена данными, когда подключения не разрываются, а допустим находятся в отдельном потоке и ждут следующего этапа обмена данными?

[kocmoc941]

Сообщение от ror13

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

Ну конкретных цифр нет, на сколько медленнее будет работать, но медленнее - однозначно, на сколько - риторический вопрос. Это зависит от размера пакетов, которые будут посылаться (соответственно их частоты посылки), т.к. в пакетах кроме "используемой" находиться ещё и служебная информация - это раз, потеря на служебную информацию, при маленьких размерах пакетов увеличится, и будет увеличиваться по мере уменьшения размера пакета (это *потеря данных, а не скорости, но при *потере данных нужно увеличить пропускную способность канала увеличением частоты посылаемых пакетов данных, а это требует увеличения скорости передачи).
Так же частота подключений/отключений влияет на скорость передачи информации, т.к. требуется дополнительное время/пакеты на подключение/отключение, ну тут я думаю пояснять ничего не надо вы и сами догадываетесь.

*потеря данных - под потерей данных я подразумеваю не физическую потерю, а уменьшения "полезных" данных в передаваемом пакете (например пакет с 50% "хлама"/50% "нужной информации", а если увеличить размер пакета и соответственно блока "полезных данных", то получим 20% "хлама"/80% "нужной информации" (цифры взял на вскидку для примера)).
ЗЫ Надеюсь понятно разъяснил, удачи!
ЗЗЫ Т.е. при малых размерах пакетов просто на-просто мы передаём чаще служебную информацию, что "чаще" забивает канал.

[veniside]

> на сколько медленней это будет работать

намного медленней )

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

[kocmoc941]

Сообщение от veniside

намного медленней )

Ну да если бы написал, что намного медленнее не ошибся бы, согласен )
Кстати ещё можно дейтаграммы, но понятно, что такой подход не всегда оправдан.