|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
04.07.2011, 03:03 | #1 |
Регистрация: 09.12.2010
Сообщений: 5
|
Организация клиент-серверного приложения
Необходимо написать многопользовательское клиент-серверное приложение без отдельного сервера, целостность данных важна.
Чтоб конкретизировать пусть это будет чат. Выбрал winsock tcp. Как я понял каждое приложение должно слушать порт (тоесть быть сервером) и естественно инициализировать соединение (клиент). С этим всё понятно а вот как лучше поступить дальше вопрос.., у меня есть несколько вариантов: 1. Запуск приложения, создание сервера, получаем компьютеры в сети, их ip и наличие открытого порта для общения, если порт присутствует посылаем запрос создания подключения и устанавливаем его, и так со всеми. Тоесть каждый участник такой сети получается как сервер, ладно при 10 потоках вроде должно быть всё норм а в от если их будет 200… в общем бредово... 2. Запуск приложения, создание сервера, получаем компьютеры в сети, их ip и наличие открытого порта для общения, если есть сохраняем ip себе. Далее если я захочу отправить сообщение то соединяюсь с каждым из своего списка айпишником и отправляю ему сообщение после чего соединение разрываю(удаляю поток). Эта идея кажется более рациональной, но на сколько медленней это будет(ну и естественно надо периодически обновлять список ip) Мб я совсем не туда капаю и есть какие-нибудь альтернативы?.. |
04.07.2011, 09:44 | #2 | |
Регистрация: 19.11.2010
Сообщений: 3
|
Цитата:
|
|
04.07.2011, 11:36 | #3 |
Регистрация: 09.12.2010
Сообщений: 5
|
я сверху и написал как реализовать две похожие идеи "без сервера", естественно без сервера это образно, тоесть каждое приложение может быть сервером... я уверен что так работать будет вопрос на сколько будет тормозить ... поэтом привёл на мой взгляд два очевидных решения, вопрос в том существует ли 3 вариант? и какой из моих 2-ух более рациональный?
вот нарисовал 1-ый вариант: 1 - по серверной свзяи сконекшен с 2-6 2- по серверной свзяи сконекшен с 3-6, а с 1 как клиент и тд.. 6 как клиент с 1-5 Второй вариант нарисовать сложно… но похоже, для второго варианта мы связь не держим, тоесть для отправки сообщение 6 создаёт коннект с 1-5 передаёт и закрывает коннект. И ещё раз повторюсь, я склонен ко второму вопрос в том какова будет потеря времени и стабильности передачи. |
04.07.2011, 13:20 | #4 |
Старожил
Регистрация: 03.01.2011
Сообщений: 2,508
|
> Мб я совсем не туда капаю и есть какие-нибудь альтернативы?
если проект будет работать только в локалке, можно мультикастом рассылать сообщения. если планируется работа и в тырнете, то забей сразу. Не будут сервера работать на каждом клиенте. Т.е. процентов 90% машин будут только клиентами. Фактически, получится то же самое, что и с выделенным сервером, только возни на порядок больше. Поэтому, имхо, если нужна работа проекта в тырнете, сразу определись, что вот эта машина будет сервером, а остальные только клиентами. Ну на крайний случай можно поднять несколько серверов и пробить их список у всех клиентов. Только смысла в этом нет особого. Так делают, если нагрузка на сервер большая, чтобы разбросать её на несколько машин. Не думаю, что чат настолько загрузит сеть )
"Когда приходит положенное время, человек перестаёт играть в пинбол. Только и всего."
|
04.07.2011, 14:14 | #5 |
Регистрация: 09.12.2010
Сообщений: 5
|
я сообразил что мне надо ещё когда картинку рисовал... уж больно она мне показалась знакомой... а получается то обычная p2p сеть... veniside благодаря за ответ на назревший ещё 1 вопрос об инет реализации, тоесть если в инет, то без сервера синхронизации, как например у битторент, никак...
и остался ещё 1 нубский вопрос. Что-то нигде не увидел на него ответа: Когда я создаю подключение отправляю данные и закрываю подключение, на сколько медленней это будет работать относительно обмена данными, когда подключения не разрываются, а допустим находятся в отдельном потоке и ждут следующего этапа обмена данными? |
04.07.2011, 14:59 | #6 | |
Новичок
Джуниор
Регистрация: 18.02.2011
Сообщений: 2
|
Цитата:
Так же частота подключений/отключений влияет на скорость передачи информации, т.к. требуется дополнительное время/пакеты на подключение/отключение, ну тут я думаю пояснять ничего не надо вы и сами догадываетесь. *потеря данных - под потерей данных я подразумеваю не физическую потерю, а уменьшения "полезных" данных в передаваемом пакете (например пакет с 50% "хлама"/50% "нужной информации", а если увеличить размер пакета и соответственно блока "полезных данных", то получим 20% "хлама"/80% "нужной информации" (цифры взял на вскидку для примера)). ЗЫ Надеюсь понятно разъяснил, удачи! ЗЗЫ Т.е. при малых размерах пакетов просто на-просто мы передаём чаще служебную информацию, что "чаще" забивает канал. Последний раз редактировалось kocmoc941; 04.07.2011 в 15:03. Причина: Добавил |
|
04.07.2011, 15:13 | #7 |
Старожил
Регистрация: 03.01.2011
Сообщений: 2,508
|
> на сколько медленней это будет работать
намного медленней ) Создание нового TCP соединения — относительно длительный трёхступенчатый процесс, который может занимать от 100 мс до 1 секунды и больше. Задержка на 1 секунду будет неприятно раздражать юзеров. Да и с точки зрения растраты ограниченных ресурсов на ерунду, такой подход не самый удачный.
"Когда приходит положенное время, человек перестаёт играть в пинбол. Только и всего."
Последний раз редактировалось veniside; 04.07.2011 в 15:17. |
04.07.2011, 16:04 | #8 |
Новичок
Джуниор
Регистрация: 18.02.2011
Сообщений: 2
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
приведите пример клиент-серверного приложения. | ромик0 | Общие вопросы C/C++ | 8 | 22.06.2011 00:01 |
Разработка клиент-серверного приложения | Sabber | БД в Delphi | 0 | 19.05.2010 12:25 |
Разработка клиент-серверного приложения на PHP | IlyaGT | Помощь студентам | 1 | 09.04.2009 10:18 |
Разработка клиент - серверного приложения | Spyer | Работа с сетью в Delphi | 5 | 16.01.2008 15:46 |