Нужно идея по рганизации Client/Server приложения

← →
Cyberdemon © (2005-08-26 12:49) [0]

Уважаемые мастера! Есть идея наисать сервер и клиента на базе TTcpServer и TTCpClient. Вроде понял как, что работает. Так вот меня осенила мысль, что в случае коннекта 2 и более пользователей на один сокет будет ошибка. Так ли это на самом деле и если да, как с этим бороться?

← →
Digitman © (2005-08-26 13:00) [1]

> Так ли это на самом деле

нет, не так.

> Вроде понял как, что работает

значит не понял

← →
Cyberdemon © (2005-08-26 13:05) [2]

т.е. одновременно десяток другой клиентов может спокойно стучаться на один порт и все они получат ответ? В примерах по сокетам об этом ничего не говорилось и отдельно не прописывалось.

← →
Digitman © (2005-08-26 13:13) [3]

> Cyberdemon © (26.08.05 13:05) [2]

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

← →
Windows © (2005-08-26 13:13) [4]

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

← →
Windows © (2005-08-26 13:19) [5]

забыл сказать, что если подключено скажем 10 клиентов, и ты посылаешь простую команду, то все будет нормально, а если ты принимаешь поток, то тут возникнут проблемы!
Хотя это тоже можно решить, перенаправляя его на н-ного подключенного клиента:) Тогда остальные будут в пролете!

← →
Digitman © (2005-08-26 13:41) [6]

> Windows © (26.08.05 13:19) [5]

> простую команду, то все будет нормально, а если ты принимаешь
> поток, то тут возникнут проблемы

ерунду несешь

← →
Cyberdemon © (2005-08-26 15:45) [7]

Кажется меня не поняли. Допустим 1-й клиент подсоединился, пообчался с сервером и начал получать файл размером скажем 600 Мб ... И в этот момент (пока передается файл)2-й клиент подключается с той же целью - пообчаться (sendln, receiveln)- и получить (а может и передать) файл меньшего или большего размера без разницы. Что в этом случае происходит? Компонента сама на потоки разведет эти соединения? Или будет сбой? Или это надо программно предусмотреть? По поводу браузера: на сколько я помню, апач загружает себя в память столько раз сколько одновременных соединений и обрабатывает их поотдельности. Причем Н-ое количество демонов изначально загружено в память. По поводу IIS ничего сказать не могу.

← →
Digitman © (2005-08-26 16:11) [8]

> Что в этом случае происходит?

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

> Компонента сама на потоки разведет эти соединения?

какая "компонента" ?
на какие "потоки" ?
изволь быть конкретен ..

> Или это надо программно предусмотреть?

смотря о каких компонентах и о каких потоках идет речь ..

> По поводу браузера

при чем здесь браузер ?

сервер, о котором идет речь, - это Апач-сервер ?

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

для Apache-сервера под Win32 это не соответствует действительности

← →
Domestos (2005-08-26 16:13) [9]

И ты думаешь, что ты передашь через компоненты 600 метров? у тебя все повиснит! Я пробовал!
И именно хочу сказать про то, когда подключается второй клиент!
Во время передачи файла, у тебя он постоянно используется, и тут дело не в порте, а в компоненте. Вот:)

← →
Digitman © (2005-08-26 16:28) [10]

> Domestos (26.08.05 16:13) [9]

> у тебя все повиснит! Я пробовал!
> И именно хочу сказать про то, когда подключается второй
> клиент

глупости.

> тут дело не в порте, а в компоненте

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

← →
Cyberdemon © (2005-08-26 17:05) [11]

2Digitman:

> тут дело - в кривых руках и/или незнании особенностей организации
> транспортного уровня с использованием того или иного компонента
> в том или ином режиме

;) ...

Вопрос был простой: сможет или нет. Учитывая все вышесказанное думаю сможет. Проверим. Протестируем. 600М передавать реально не планировал, но попробую. Использую компоненты: TTcpClient и TTcpServer. Интересно, почему все остальные (судя по форуму) используют TServerSocket и TClientSocket (то что они есть в Д7 я знаю ;))? Это лучшие компоненты? Чем они отличаются от используемых мной? Чем лучше ... хуже? Почему не использовать подобные компоненты от INDY? Когда их (от INDY) лучше юзать?

2Digitman: Если у Вас прямые руки и Вы знаете особенности
> транспортного уровня с использованием того или иного компонента
> в том или ином режиме

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

← →
Cyberdemon © (2005-08-26 17:13) [12]

А вот кстати и исходные тексты примеров:

КЛИЕНТ
procedure TForm1.Button1Click(Sender: TObject); var s:string; buf: array[0..128] of char; len,l,l1,i:integer; f:file of char; begin TcpClient1.Active:=true; TcpClient1.RemoteHost:=Edit2.Text; TcpClient1.RemotePort:=Edit3.Text; try TcpClient1.Sendln(Edit1.Text); Memo1.Lines.Add("Send: "+Edit1.Text); s:=TcpClient1.Receiveln; Memo1.Lines.Add("Receiving: "+s); len:=strtoint(s); l:=0; AssignFile(f,"c:\output.txt"); Rewrite(f); repeat l1:=TcpClient1.ReceiveBuf(buf[0],128,0); l:=l+l1; for i:=0 to l1-1 do Write(f,buf[i]); until l=len; finally if TcpClient1.Connected then TcpClient1.Disconnect; CloseFile(f); Memo1.Lines.LoadFromFile("c:\output.txt"); end; end;

СЕРВЕР
procedure TForm1.TcpServer1Accept(Sender: TObject; ClientSocket: TCustomIpClient); var s:string; // buf:array[0..128] of char; fs:TFileStream; begin Memo1.Lines.Add("Remote Host :"+Clientsocket.LookupHostName(clientsocket.RemoteHost)+"("+clientsocket.RemoteHost+")"); s:=ClientSocket.Receiveln; Memo1.Lines.Add("Accept data: "+s); if s="S" then begin fs:=TFileStream.Create("C:\agpsetup.txt",fmOpenRead); ClientSocket.Sendln(inttostr(fs.Size)); ClientSocket.SendStream(fs); fs.Free; Memo1.Lines.Add("Sended stream"); end; end;

> Интересно, почему все остальные (судя по форуму) используют
> TServerSocket и TClientSocket

потому что это очень простые компоненты, реализующие чистой воды транспортный уровень, безо всяких прикладных "наворотов", характерных, например, для Indy, где большинство компонентов реализует прикладную надстройку над транспортом, позволяя программеру сосредоточиться на прикладной логике

прозрачность классов TClient/ServerSocket в простой реализации и гибкой логике как раз и делает их привлекательными на фоне прочих гнездовых компонентов, где транспортный уровень как правило ненагляден и скрыт под прикладным

Инди же - кросплатформенный пакет.
Выигрывая в легкой переносимости на другую платформу, Инди проигрывает в гибкости и возможностях использования гнездового транспорта на платформе Win32

TTCPClient/Server, если угодно, занимают промежуточную нишу.
С одной стороны, эти компоненты , ориентированные как и TClient/ServerSocket на Win32, реализуют "улучшенную" (с т.з. Борланда) логику контроля/управления гнездовым транспортом, нежели "устаревшие" TClient/ServerSocket. С другой стороны, ничего революционно нового Борланд не привнес TTCPClient/Server - компоненты как и прежде реализуют только транспортный уровень, Борланд лишь переработал программный интерфейс этих компонентов и исправил некоторые досадные недоразумения, характерные для логики TClient/ServerSocket

> Может быть более менее развернутую статейку напишешь?

материалов в Сети по этим компонентам - навалом.
зачем изобретать еще один велосипед ?

> вот кстати и исходные тексты примеров

и на какой строчке происходит "ошибка" ?

2Digitman: ошибок нет. Это рабочий пример через 1 час после начала изучения данного направления. За посты спасибо. Тема закрыта. Пример выложил, т.к. с этими компонентами примеров в сети нашел только один - в Японии, и то только для клиента. Здесь и клиент и сервер. Основные функции представлены для общего пользования. Думаю используя данный пример можно и 600Мб переслать безболезненно разумеется с использованием Progressbar и Application.ProcessMessage. Всем спасибо, было приятно пообщаться.

P.S.
А по поводу статьи подумай, может все таки стоит. Сеть копал довольно сильно, но ответов на поставленные вопросы влет не нашел. Да и на данном ресурсе не густо.

>>Это рабочий пример через 1 час после начала изучения
Видать все таки 1 часа маловато, т.к. в примере грубейшие ошибки причем не одна.
:)

для клиент - серверных приложений уже можно и СОМ+ использовать...

Нужно идея по рганизации Client/Server приложения Найти похожие ветки