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 варианта работы: клиент подключился, отправил, отключился. Надо собрать с порта до того как он отключится. И ещё: клиент подключился, отправил, получил ответ, я его отключил.

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

На то существует неблокирующий режим.
Но в Инди он не реализован по ряду важных причин.
Зато реализован в 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? Время жизни потока в ожидании данных или время жизни потока вообще? Не понимаю...

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

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

> Какой смысл имеет 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 уже будет уничтожен?

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

Нет.

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

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