Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.10.28;
Скачать: CL | DM;

Вниз

ServerSocket :: What are differents?   Найти похожие ветки 

 
Alexey (AZ)   (2006-11-13 13:01) [0]

servertype - тип сервера. Может принимать одно из двух значений: stnonblocking - синхронная работа с клиентскими сокетами. При таком типе сервера Вы можете работать с клиентами через события onclientread и onclientwrite. stthreadblocking - асинхронный тип. Для каждого клиентского сокетного канала создается отдельный процесс (thread).
Добрый день. Сразу введу в курс дела. Нужен сервер, к которому могут только подключаться и отправлять инфу, отключением клиентов занимаюсь я. Есть идея сделать по таймеру так...
 for i:=1 to Serv.Socket.ActiveConnections do
   Memo1.Text := Serv.Socket.Connections[i-1].ReceiveText;

...и считывать с клиенов их послания так, а НЕ через событие ClientRead, затем отключать. Вопросы:
1) Будет ли накапливаться где-то инфа, если клиент отключится до того как я считаю (после дисконнекта я считать не смогу)?
2) Какой размер этого буфера?
3) СтОит ли копать в сторону stBlocking? Если да, то на что обратить внимание? (сейчас стоИт stNonBlocking)

Благодарю за внимание.


 
Alexey (AZ)   (2006-11-13 13:10) [1]

Т.е. я прошу объяснить различия между типами сокетов, и хочу узнать что для каких целей применять.


 
Anatoly Podgoretsky ©   (2006-11-13 13:17) [2]

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


 
Alexey (AZ)   (2006-11-13 13:39) [3]

Справка отсюда:
http://articles.org.ru/cfaq/index.php?qid=1891&frommostrecent=yes
Я честно говоря в некотором замешательстве... что из методов/событий/свойств этого сокета мне нужно использовать (т.е. что ЛУЧШЕ использовать, т.к. я уже два способа перепробовал).


 
Anatoly Podgoretsky ©   (2006-11-13 13:55) [4]

> Alexey (AZ)  (13.11.2006 13:39:03)  [3]

Не, ну я на подобный источник не пойду, за здоровье опасаюсь.
Что значит нужно? и что значит лучше?
Это же задачей определяется.

--


 
DVM ©   (2006-11-13 14:08) [5]


> сокетного канала создается отдельный процесс (thread).

Может поток все-таки?

> 1) Будет ли накапливаться где-то инфа, если клиент отключится
> до того как я считаю (после дисконнекта я считать не смогу)?
>  

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


> 2) Какой размер этого буфера?
Какой сделаешь, такой и будет.


> 3) СтОит ли копать в сторону stBlocking? Если да, то на
> что обратить внимание? (сейчас стоИт stNonBlocking)

Без разницы. Можно и так и так хорошо сделать.

> Т.е. я прошу объяснить различия между типами сокетов, и
> хочу узнать что для каких целей применять.

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


 
Anatoly Podgoretsky ©   (2006-11-13 15:01) [6]

> DVM  (13.11.2006 14:08:05)  [5]

> Вторые программировать сложнее немного.
> Для сервера используют чаще блокирующие сокеты, помещая в потоки, для клиентов неблокирующие, хотя это как кому нравится.

Не могу согласиться не с первым, не со вторым тезисом, особенно про потоки.
Кроме (не)блокирующих есть еще синхронные/асинхронные, а в статье между ними поставлен знак равенства. Синхронный сокет совсем не обязан блокировать поток и наоборот. К сожалению здесь ноги растут из такой глубины, из-за различия в терминологии на ранних стадиях развитияю. Я бы просто не использовал термины блокирования, как малоговорящие.

Потоки сами по себе, а сокеты сами по себе.

--


 
DVM ©   (2006-11-13 15:15) [7]


> Кроме (не)блокирующих есть еще синхронные/асинхронные,

я в курсе

> а в статье между ними поставлен знак равенства.

Я безотносительно статьи какой-то там. Я ее даже не глядел.

> Синхронный сокет совсем не обязан блокировать поток и наоборот.

Согласен, но я про синхронность/асинхронность даже не упоминал.

> Потоки сами по себе, а сокеты сами по себе.

А никто не говорит, что они как-то пересекаются.
Я имел ввиду, что функции работы с блокирующими сокетами блокируют вызывающий поток. Те же самые функции немедленно возвращают управление для сокетов находящихся в неблокирующем режиме.

Для меня блокирующий сокет это сокет для кторого выполнено
     Block := 1;
     ioctlsocket(Socket, FIONBIO, Block);
Неблокирующий:
      Block := 0;
      ioctlsocket(Socket, FIONBIO, Block);


 
DVM ©   (2006-11-13 15:17) [8]

т.е. 1 и 0 наоборот


 
Сергей М. ©   (2006-11-13 15:21) [9]


> 2) Какой размер этого буфера?


см. ф-цию Winsock.GetSockOpt(), опция SO_RCVBUF


> 3) СтОит ли копать в сторону stBlocking?


Стоит, если транспортный тред не будет заниматься ничем иным, как только приемом/передачей


 
Anatoly Podgoretsky ©   (2006-11-13 15:30) [10]

> DVM  (13.11.2006 15:15:07)  [7]

Это ошибки терминологии, они похожи внешни и ранее не делали разницы, на самом деле первый синхронный, а второй асинхронный.


 
Anatoly Podgoretsky ©   (2006-11-13 15:31) [11]

> DVM  (13.11.2006 15:17:08)  [8]

Тогда и у меня наоборот.

--


 
Alexey (AZ)   (2006-11-16 16:36) [12]

Сергей М. ©   (13.11.06 15:21) [9]
> Стоит, если транспортный тред не будет заниматься ничем
> иным, как только приемом/передачей

Моей задачей является написание сервера, работающего с БД и управляемого с помощью потоконебезопасных VCL. Функции проги следующие: принимать от юзеров команды, выгребать БД и отсылать мегабайты обратно. Иногда логировать в Мемо и т.п.


 
DVM ©   (2006-11-16 16:41) [13]


> Функции проги следующие: принимать от юзеров команды, выгребать
> БД и отсылать мегабайты обратно

По моему это трехуровнеая схема. В Делфи уже реализовано.


 
Alexey (AZ)   (2006-11-16 16:51) [14]

Я пользуюсь ADOConnection, ADOQuery & DataSource. У нас особый формат команд (фактически придумали протокол). В зависимости от этих команд моя прога формирует запросы... вот так и работает.


 
DVM ©   (2006-11-16 16:54) [15]


> У нас особый формат команд (фактически придумали протокол).
>  В зависимости от этих команд моя прога формирует запросы.
> .. вот так и работает.

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


 
Сергей М. ©   (2006-11-17 09:10) [16]


> Alexey (AZ)   (16.11.06 16:36) [12]


Понятно.

Пробуй stThreadBlocking.


 
Alexey (AZ)   (2006-11-23 19:15) [17]

Сергей М. ©   (13.11.06 15:21) [9] , thx!

Ужос с потоками. Оказалось что для клиента есть разница какой на сервере сокет. И похоже, что клиент работает в неблокирующем. Думаю выбрать indy как замену T[X]Socket.

У меня остались вопросы:
1) В IdTCPServer есть ReadString(X) (или типа), читающий X знаков, и есть ReadLn. Плохо то, что для ReadLn и т.п. надо указывать "символы конца строки", либо кол-во байт. А есть ли что-нибудь типа ReceiveText как в (T[X]Socket), дапбы собрать с порта всё что есть?

2) Если у меня на форме есть ADOConnection и ADOQuery с DataSource"м, а я собираюсь делать потоки, то можно ли как вариант создавать на каждый трэд по ADOQuery с DataSource"м и соединять их на единственный ADOConnection?

Может быть есть другие способы, самому наступать на грабли просто некогда, м.б. присутствуют наступившие и расскажут новичку как надо :)

Anatoly Podgoretsky ©   (13.11.06 15:30) [10] , посмотрел Ваш перевод книги про indy. К сожалению автры мало рассказали о сервере, работающем на OnExecute (вместо этого внимание уделено командному режиму).


 
Anatoly Podgoretsky ©   (2006-11-23 19:43) [18]

> Alexey (AZ)  (23.11.2006 19:15:17)  [17]

Клиент ничего не знает про сервер, даже на какой ОС он реализован и чем. Это базовое правило сетей.

> 1. Плохо то, что для ReadLn и т.п. надо указывать "символы конца строки",

Почему плохо, как раз наоборот, позволяет работать с любой ОС

> 2. можно ли как вариант создавать на каждый трэд по ADOQuery с DataSource"м и соединять их на единственный ADOConnection?

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


 
Alexey (AZ)   (2006-11-23 20:56) [19]

Позвольте тогда вопрос: какого Connections.readln либо connections.readstring(1) (или как там его) висит, если в порте нет данных?


 
Сергей М. ©   (2006-11-24 08:12) [20]


> Alexey (AZ)   (23.11.06 20:56) [19]


А почему он не должен "висеть" ?
Как ты себе видишь работу этих методов ?


 
Alexey (AZ)   (2006-11-24 20:22) [21]

Нашел ещё статью.
http://www.codenet.ru/progr/delphi/stat/TServerSocket.php
По инди: если я понятия не имею о том, что мне будут отсылать, то как считать всё что есть порте? Т.е. я не знаю ни размер отправляемых мне данных, ни их terminator char (в общем понятно). Вот шлют мне бинарную херь, требующую немедленной обработки, и что тогда? Т.е. мне некогда ждать, пока заполнится буфер.

> Как ты себе видишь работу этих методов ?

Как в TServerSocket. Он же может съесть всё с порта, а если там ничего нет, то он и съест ничего, но висеть на этой инструкции не будет.


 
Alexey (AZ)   (2006-11-24 20:44) [22]

Возможны 2 варианта работы: клиент подключился, отправил, отключился. Надо собрать с порта до того как он отключится. И ещё: клиент подключился, отправил, получил ответ, я его отключил.


 
Сергей М. ©   (2006-11-27 08:30) [23]


> Т.е. мне некогда ждать, пока заполнится буфер


На то существует неблокирующий режим.
Но в Инди он не реализован по ряду важных причин.
Зато реализован в TServer/ClientSocket.


> Как в TServerSocket. Он же может съесть всё с порта, а если
> там ничего нет, то он и съест ничего, но висеть на этой
> инструкции не будет.


Сказанное справедливо только для неблокирующего режима.


 
Alexey (AZ)   (2006-11-29 13:27) [24]

Сергей М., благодарствую за разъяснения!


 
Alexey (AZ)   (2007-02-23 21:37) [25]

И ещё один вопрос.
Stream := TWinSocketStream.Create(ClientSocket, TimeOut);
Какой смысл имеет TimeOut? Время жизни потока в ожидании данных или время жизни потока вообще? Не понимаю...


 
medved_68 ©   (2007-02-26 08:54) [26]


> Время жизни потока в ожидании данных или время жизни потока
> вообще? Не понимаю...

Время жизни потока при отсутствии активности сокета.


 
Сергей М. ©   (2007-02-26 10:31) [27]


> Какой смысл имеет TimeOut?


Время (в миллисекундах), не более чем на которое будет блокироваться нить, вызывающая методы Read[Buffer], Write[Buffer] при любом (успешном или неуспешном) исходе запрашиваемой операции чтения/записи.

Простой пример:

Таймаут = 1000 (1 секунда)

Принимающая сторона запрашивает к чтению из потока, скажем, 10 байт.

Если в течении не более секунды во вх.потоке окажутся доступными для чтения не менее чем 10 байт, метод Read[Buffer] вернет управление с результатом 10

Если по прошествии секунды во вх.потоке окажутся доступными менее 10 байт, метод Read вернет управление с результатом < 10, а метод ReadBuffer возбудит исключение EReadError


 
Alexey (AZ)   (2007-02-27 10:04) [28]

Понятно, а если таймаут = 1 секунде, я вычитал из порта всё тчо надо и затем идёт операция обработки данных (5 секунд) и мне нужно отправить данные обратно, то SocketStream уже будет уничтожен?


 
Сергей М. ©   (2007-02-27 10:52) [29]


> SocketStream уже будет уничтожен?


Нет.

Уничтожение стрима - это явный вызов тобой метода TWinSocketStream.Free. Пока ты не вызвал этот метод, стрим продолжает существовать.



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

Текущий архив: 2007.10.28;
Скачать: CL | DM;

Наверх




Память: 0.55 MB
Время: 0.014 c
2-1191579972
Mariya
2007-10-05 14:26
2007.10.28
Объявление переменной


15-1191409720
PPop
2007-10-03 15:08
2007.10.28
Ну как указать этот Main-Class в файле manifest.mf?


4-1177402203
Malik
2007-04-24 12:10
2007.10.28
ChekedBox


2-1191835263
alikon1
2007-10-08 13:21
2007.10.28
сделать кнопки не активными


15-1190783124
nikolay-gavrilov
2007-09-26 09:05
2007.10.28
TWSocket - SSL Effort