Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];

Вниз

Создание клиент-серверного сетевого чата   Найти похожие ветки 

 
Тема   (2007-01-07 02:18) [0]

Доброй ночи, уважаемые программисты!У меня возникла проблема. В локальной сети у нас ~150 человек. Хочу написать сетевой чат для этой сети. Естественно он должен быть клиент-серверный при таком количестве человек, UDP тут не катит. Как можно реализовать передачу файлов между пользователями в данной ситуации, минуя прохождение данных через сервер. То есть сервер должен только установить соединение между клиентами, а передача должна идти только между ними, иначе, как вы понимаете сервак будет загружен, и, следовательно, скорость передачи будет просто мизерной.
Мне кажется, надо использовать компоненты IdTCPClient и IdTCPServer с вкладок Indy. С Delphi идет пример чата с использованием этих компонентов, но там только пример передачи строчного сообщения, и принцип такой: клиент отсылает сообщение на сервер, сервер принимает его и через цикл отсылает всем необходимым пользователям (функции WriteLn() и ReadLn()). Если использовать функции WriteStream() и ReadStream() этих компонентов, то принцип передачи потока, как я понимаю, будет осуществляться через сервер и ничего хорошего не получится.
Что делать? Help...


 
Dmitrij_K   (2007-01-07 03:15) [1]

Общий алгоритм передачи файла.
1. Принимающая сторона открывает порт для прослушивания.
2. Отдающий соединяется с принимающим.
3. Отдающий посылает имя файла, размер его и само содержание файла принимающей стороне.
4. Принимающий читает имя файла, его размер и читает данные из сокета
5. Оба разрывают соединение

На каком пункте проблема?
----------------------------
ЗЫ
Примеров в сети навалом, искать надо уметь.


 
Тема   (2007-01-07 14:09) [2]

То есть получается, можно сделать так. Серверное приложение содержит TServerSocket. Клиенты будут иметь один компонент TClientSocket для постоянной связи с сервером и еще два компонента TClientSocket и TServerSocket для кратковременной связи между собой при передаче файлов (либо компоненты Indy).
Тогда 1 вопрос. Если, например, один клиент открывает порт скажем 1000 и принимает файл от другого клиента, и третий клиент открывает тоже 1000 порт и принимает файл от четвертого клиента, то что произойдет. И если так делать нельзя, то что делать? Перед передачей файла сканить сеть на открытые порты и открывать клиенту свободный порт?, что весьма напряжно. Или можно все делать на одном порте, ведь клиенты разные?
И еще вопросик. Я уже реализовывал такой принцип при модемном соединении двух компов, но возникла проблема: только один из компов мог открывать порт на прослушивание, то есть, например, когда 1 комп передавал запрос на открытие порта на 2, то 1 не мог соединиться со вторым, только 2 мог соединиться с первым. От чего это могло зависеть? Иза модемного соединения или нет?


 
Sha ©   (2007-01-07 14:14) [3]

> Тема   (07.01.07 02:18)  
> Естественно он должен быть клиент-серверный
> при таком количестве человек, UDP тут не катит.

Почему естественно?


 
Тема   (2007-01-07 14:22) [4]

Sha << По крайней мере чаты VyChat и NASSY не справляются. Естественно, они не справятся, ведь каждый клиент каждую секунду пингует всю сеть, да тех, у кого этот чат не запущен. Принцип широковещания такой. Сеть вообще зависает от этого при таком количестве пингующих клиентов.


 
Anatoly Podgoretsky ©   (2007-01-07 14:23) [5]

> Тема  (07.01.2007 14:09:02)  [2]

Ты напрасно рассматриваешь порт в отрыве от адреса


 
Тема   (2007-01-07 14:24) [6]

Dmitrij_K << Пордон, ведь сервер может вести статистику открытых портов и сканить сеть на порты не надо. Но вопрос все равно в силе, ведь если чат не серверный, а широковещательный UDP, то там сервера нет и как в таком случае открывать порты.
Ведь лучше писать универсальный чат, который при отключении сервера переходит в режим широковещания и наоборот.


 
Тема   (2007-01-07 14:27) [7]

Anatoly Podgoretsky << То есть ты имеешь ввиду, что два клиента на 1000 порту и два других клиента на 1000 порту одной сети будут уживаться нормально, т.к. у них разные IP?


 
Sha ©   (2007-01-07 14:55) [8]

> Тема   (07.01.07 14:22) [4]
> ведь каждый клиент каждую секунду пингует всю сеть
> Принцип широковещания такой.

Чушь. Как это связано с UDP multicast?


 
Тема   (2007-01-07 16:48) [9]

Sha << А как по твоему чат узнает кто в данный момент в сети. Он пингует всю сеть, даже тех у кого чат не запущен, поэтому, т.к. в сети более 50 человек, возникают серьезные глюки, и знающие люди из сети наказывают тех, кто тайком общается в сети через эти UDP чаты, ведь тормозит вся сеть от этого.


 
Anatoly Podgoretsky ©   (2007-01-07 16:53) [10]

> Тема  (07.01.2007 16:48:09)  [9]

> Он пингует всю сеть

Зачем, он что спамер у вас или хакер?


 
Sha ©   (2007-01-07 17:01) [11]

> Тема   (07.01.07 16:48) [9]
> А как по твоему чат узнает кто в данный момент в сети.

Чат это кто? В сети - это где?
А принять сообщение готовы те, кто однажды сообщил об этом и от своих слов не отказался.

> Он пингует всю сеть, даже тех у кого чат не запущен

Выбрось эту чушь из головы. Постоянно пинговать нет надобности.

> знающие люди из сети наказывают тех, кто тайком общается в сети
> через эти UDP чаты, ведь тормозит вся сеть от этого

Наказывают все-таки за тормоза и за UDP? :))
Определенно, некоторым писателям вредно чаты писать :))


 
Тема   (2007-01-07 18:48) [12]

Sha >> Выбрось эту чушь из головы. Постоянно пинговать нет надобности.
Sha << Есть надобность. А насчет UDP я имел ввиду, что при написании клиент-серверного чата надо использовать TCP/IP, а не UDP (хотя UDP намного быстрее, любому известно, что в больших сетях UDP не эффективен). И это естественно, что в больших сетях целесообразнее использовать клиент-серверный чат. Кстати, про пинговку посмотри :))


 
Тема   (2007-01-07 18:57) [13]

Sha << И, кстати, насчет UDP. Я имел ввиду, что его нецелесообразно использовать при передаче файлов, т.к. нам нужна целостность данных.


 
kaZaNoVa ©   (2007-01-07 19:03) [14]

Тема   (07.01.07 18:57) [13]
заюзай TCP-IP чат 1 сервер и все к нему коннектятся .. если что могу выложить такую наработку с шифрованием траффика и сжатием !


 
kaZaNoVa ©   (2007-01-07 19:04) [15]

файлы лучше всего передавать через FTP-сервер .. ИМХО ... никакх проблем с огромными файлами и докачкой .......


 
Sha ©   (2007-01-07 22:33) [16]

> Тема   (07.01.07 18:48) [12]
>> Выбрось эту чушь из головы. Постоянно пинговать нет надобности.
> Есть надобность.

Обоснуй ))

> А насчет UDP я имел ввиду, что при написании клиент-серверного чата надо использовать TCP/IP, а не UDP
>(хотя UDP намного быстрее, любому известно, что в больших сетях UDP не эффективен).

Насколько больших?
Я - любой, но мне не известно. Жду разъяснений, почему не эффективен. ))

> Кстати, про пинговку посмотри :))

Про пинг я знаю гораздо больше, чем ты думаешь ))

> И, кстати, насчет UDP. Я имел ввиду, что его нецелесообразно
> использовать при передаче файлов, т.к. нам нужна целостность данных.

Как связан протокол передачи, с целостностью данных?
У тебя каша в голове.


 
Dmitrij_K   (2007-01-07 22:45) [17]


> Как связан протокол передачи, с целостностью данных?

Напрямую связано
http://ru.wikipedia.org/wiki/TCP
http://ru.wikipedia.org/wiki/UDP


 
Anatoly Podgoretsky ©   (2007-01-07 22:52) [18]

> Dmitrij_K  (07.01.2007 22:45:17)  [17]

Не приводи ссылок, которые не понимаешь, или когда не понимаешь, что тебе сказали.


 
Sha ©   (2007-01-08 00:04) [19]

> Dmitrij_K   (07.01.07 22:45) [17]
>> Как связан протокол передачи, с целостностью данных?
> Напрямую связано

Цитату, плиз, про нарушение целостности данных при использовании
протокола UDP. Если не найдешь, можно своими словами объяснить ))


 
Тема   (2007-01-08 00:48) [20]

Sha >> Как связан протокол передачи, с целостностью данных?
Sha << Напрямую связано. Разберись с протоколами. Любую книгу по TCP/UDP почитай, там написано про целостность данных. Я про то, что при передачи через UDP эту целостность надо контролировать самостоятельно, а если не контролировать, то нет гарантии, что данные полностью дойдут. Поэтому TCP проще в этом отношении и надежнее.
Про пинговку: как ты объяснишь явление, когда клиент нажимает скажем RESET и у всех клиентов в чате он исчезает из списка через некоторое время, ведь тут соединения друг с другом и с сервером нет.
Вот цитата из VyChat:

[0:23] Gusak вышел из Vypress Chat (превышено время ожидания ответа)

Это явный пинг. Если нет - докажи.


 
Sha ©   (2007-01-08 02:32) [21]

> Тема   (08.01.07 00:48) [20]
>  Разберись с протоколами.


Зачем мне это, я где-то допустил ошибку или неточность?
Или оставил твой вопрос без ответа? :))


> Я про то, что при передачи через UDP эту целостность надо контролировать самостоятельно
> а если не контролировать, то нет гарантии, что данные полностью дойдут.


Гарантированная доставка пакетов и целостность передаваемых данных -
совершенно разные понятия. И контролируются при помощи разных средств.
Придерживайся, пожалуйста, принятой терминологии.

> [0:23] Gusak вышел из Vypress Chat (превышено время ожидания ответа)
> Это явный пинг. Если нет - докажи.


Это доставка пакетов с подтверждением.


 
Sha ©   (2007-01-08 03:17) [22]

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


 
Officeman   (2007-01-11 08:11) [23]

Господа!

обычно происходит так.   коннект - ответ - запрос и передача - дисконнект.

вопрос: как сделать

коннект - ответ -
запрос и передача
запрос и передача
запрос и передача
запрос и передача
запрос и передача
....(NN раз)
- дисконнект

т.е. передать много данных.  например при реализации интернет игры.
один раз соединившись. производить много передачи данных. и по команде пользователя разъединится.

p.s. пробовал. неполучается на стандарноых компонентах D6.


 
Сергей М. ©   (2007-01-11 08:17) [24]


> пробовал. неполучается


Показывай как пробовал ..


 
Джо ©   (2007-01-11 08:20) [25]

> [23] Officeman   (11.01.07 08:11)

Ты тот пример уже усвоил, который я тебе выкладывал (от Lamers@fools.ua)?


 
Officeman   (2007-01-11 09:34) [26]

2Джо,  угу.

Вопрос. при отправки сообщения создаётся новое соединение.
и потом disconnect. т.е. вечное юзание сервера. мне так ненадо.
нужно. Клиент соединился. всё зашибись). теперь передаём сообщения
столько раз - сколько требуется.  Почемуто при отправке второго соообщения
TcpClient1.ReceiveLn()   уже ничему неравен. .. но если сделать дисконнект и нова коннект. то проходит новое сообщение.

Сервер

procedure TForm1.TcpServer1Accept(Sender: TObject;  ClientSocket: CustomIpClient);
begin
// получили Пароль от клиента
pas:=ClientSocket.ReceiveLn;
//...
//ответ от сервера - передача сообщения зарегистрированному пользователю
//if  pas=Trim(user)  then ....................
ClientSocket.SendLn(mess); // отсылаем сообщение
end;


Клиент


procedure TForm1.Connect1Click(Sender: TObject);
begin
TcpClient1.RemoteHost:="127.0.0.1";
TcpClient1.RemotePort:="8888";
TcpClient1.Connect;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
if TcpClient1.Connect  
then begin
  TcpClient1.SendLn(pass); // послали пароль
  Edit1.Text:=TcpClient1.ReceiveLn();   // приняли сообщение
end
else MessageBox(Handle, "Сервер не найден!", "Error", 16);
end;
end;


 
Сергей М. ©   (2007-01-11 09:44) [27]

Ты вообще-то понимаешь, когда возникает событие TcpServer.OnAccept и что оно означает ? Справку штудировал ?


 
Officeman   (2007-01-11 10:05) [28]

2Сергей М.
ааа.... ;) TcpServer.OnAccept   создаёт новый сокет оказывается.
потому у меня тока одно сообщение и проходит. т.е.
значит есть ещё внутренние события для отправки и получени сообщений.
тока незнаю какие.

вопрос в другом. я запутался какие компоненты выбрать для использования их возможностей в игровом пошаговом интернет проекте. (клиент-сервер)

1.  (ServerSocket1,ClientSocket1)
2.  (TcpServer1,IdTCPClient1) Indy
3.  свои


 
Сергей М. ©   (2007-01-11 10:11) [29]


> TcpServer.OnAccept   создаёт новый сокет оказывается


Нет, не создает.
На момент возникновения этого события новый сокет уже создан, о чем собственно это событие и говорит.


> есть ещё внутренние события для отправки и получени сообщений.
>
> тока незнаю какие.


Справку читать наконец будем или нет ?
OnSend, OnReceive видишь там ?


> какие компоненты выбрать


Бери любые.


 
Officeman   (2007-01-11 11:00) [30]

спасибо за ответы.

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


 
Сергей М. ©   (2007-01-11 11:04) [31]


> использовать любые нерационально при написании серверной
> части игрового проекта


"Нерационально" это как ? И почему ?
Только не надо тут про "слишком большой экзешник")


> будем писать на винсокетах


А все вышеперечисленные тобой компоненты что, не на "винсокетах" написаны по-твоему ?


 
Zeqfreed ©   (2007-01-11 11:32) [32]

А какие такие тормоза возникают при использовании VypressChat? У нас в локалке пока около 60 человек максимум одновременно, работает сносно. Кстати, если хочется посмотреть на реализацию, можно взять исходники Trix"а (trix.sf.net) - клиент под линукс, поддерживает протокол VypressChat версии 2.0.


 
Officeman   (2007-01-11 12:46) [33]

я понимаю вопрос немного некорректный. но как узнать максимально возможное колличесво подсоединенных клиентов - при условии что задержка у клиентов с широким каналом будет не более 10 секунд (клиент-сервер-клиент)

-мне бы узнать результат работы при 3"000 пользователей на одном сервере.
допустим чат, с использованием клиент-сервера на WinSockets

При условии:
- сервер. терминал в аренду у ГолденТелеком(Москва). - мощная выч.станция
- клиенты по всей России.

алгоритм серверной части поддерживает списки заданий.

-какая будет примерно задержка получении ответа от сервера для 3"000-го  клиента подключен.к серверу в реал тайм  ?


 
Officeman   (2007-01-11 12:53) [34]

на примере чата. список участников ненадо отсылать всем сразу. только по запросу клиента. Чат состоит из комнат. максимально в комнете может присутствовать 100 человек. т.е. таких комнат будет до 30 штук.
сообщения крутятся внтури одной комнаты.  програмно для каждой новой созданной комнаты создаётся отдельная виртуальная среда(на сервере) ведётся обработка этих данных


 
Сергей М. ©   (2007-01-11 13:28) [35]


> как узнать максимально возможное колличесво подсоединенных
> клиентов


Узнать у кого ?


> какая будет примерно задержка получении ответа от сервера
> для 3"000-го  клиента


В среднем примерно такая же, как и для любого другого клиента этого сервера.


 
Officeman   (2007-01-11 13:30) [36]

да. т.е.  

сколько может работать одновременно клиентов.
при условии, один клиент хавает трафика 1 Kb/мин.  (усредненно)

вообще это возможно расчитать без физич. сервера???

или всё это напрямую зависит от множества факторов
и предугадать PING при 3"000 пользоваттелей невозможно ????
и предугадать PING при 8"000 пользоваттелей невозможно ????


 
Officeman   (2007-01-11 13:33) [37]

получили заказ на игровой интернет проект.
нужны реальные цифры. что досягаемо, а что запредельно.


 
Сергей М. ©   (2007-01-11 13:49) [38]


> всё это напрямую зависит от множества факторов


Именно так.


> предугадать PING при 3"000 пользоваттелей невозможно ?


Причем здесь PING ?
Ты что, ICMP-сервер пишешь ?


> получили заказ на игровой интернет проект.
> нужны реальные цифры. что досягаемо, а что запредельно.


Рекомендую отказаться, пока не поздно.
С такими знаниями проект обречен на провал.


 
Officeman   (2007-01-11 14:02) [39]


>Рекомендую отказаться, пока не поздно.
>С такими знаниями проект обречен на провал.


это ваше личное мнение.


 
Anatoly Podgoretsky ©   (2007-01-11 14:08) [40]

> Officeman  (11.01.2007 14:02:39)  [39]

Мнение?
Простое наблюдение.



Страницы: 1 2 вся ветка

Форум: "Начинающим";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.56 MB
Время: 0.092 c
15-1168025419
Галинка
2007-01-05 22:30
2007.01.28
Ищу ветку


15-1168411061
pavel_guzhanov
2007-01-10 09:37
2007.01.28
Наверное еще не все потеряно :o))


2-1168583532
Roma L
2007-01-12 09:32
2007.01.28
MDIChild окно в DLL


15-1167902800
vitv
2007-01-04 12:26
2007.01.28
Посоветуйте книгу по алгоритмам


2-1168081609
Antoha111
2007-01-06 14:06
2007.01.28
Array of Byte в String





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский