Привет всем!
Ребят нужна оперативная помощь.
Я пишу многопоточный сервер/клиент на TServerSocket и TClientSocket
Делаю так:
У меня есть запись(record) определенной структуры в ней есть переменная fCommand: Word;
Я заполняю эту структуру данными и передаю таким же образом эти данные принимаются затем структура заполняется даннымии распознается

проблема в том что в локальной сети всё без ошибок, а вот по инету помимо моих пакетов приходят еще какие то данные которые не распознаются (т.е. например вместо команды fCommand содержит 0), что это за данные, чем отличается передача данных в локальной сети от передачи через инет?

как принимаешь и передаешь?
Что-то мне подсказывает (стандартная ошибка), что не учитываются результаты Socket.ReceiveBuf и Socket.SendBuf

Добавлено через 7 минут и 21 секунду

Ой-е, вопрос отменяется.
Не работаю и не буду работать в многопоточном режиме, не знаю, как там всё устроено.

передаю так


FillTData это


//принимаю так. это соответственно происходит в потоке который постоянно проверяет на входящие данные

Смотрите получается так:
сервак шлет данные и сразу получает какие то пустые пакеты, хотя клиент не отправлял данные я имею ввиду что команды или пакеты я не посылал в ответ серверу.
Предполагаю что когда сервер шлет какой либо пакет, то стандартно приходят какие то данные о подтверждении, что пакет этот доставлен, но так как у меня эти данные преобразутся в мою структуру, то я вижу пустой пакет(record)
возможен ли такой вариант?

мне бы такую уверенность, что пришло данных ровно на 1 структуру, ни байтом больше или меньше.
Даже в локалке вероятность такого (+-) достаточно велика. Не говоря уже про глобальную сеть.
Ввести проверки, сколько пришло.
Если меньше - ждать следующей порции.
Если больше - выбирать SizeOf данных, а хвост - запоминать для стыковки со следующим пакетом.

Добавлено через 4 минуты и 8 секунд

Поэтому нужно анализировать количество реально прочитанного


Вот еще что непонятно - сокет создан в основном потоке, так (лежит-то он на форме)? Почему же обращение по выборке данных идет из дополнительного? Это несколько не-потокобезопасно.

Это ведь не Визуальный компонент почему не потокобезопасно?



тоесть так?


Это сообщение отредактировал(а) Antony41 - 11.2.2013, 20:43

не совсем. Под анализом я имел ввиду проверку i
Вот так делается у меня:




Давайте возьмем за аксиому, что переключение между потоками происходит в любой момент. Этот момент определяется виндой и повлиять на него возможно только специальными методами, например - использованием объектов синхронизации (критические секции, мьютексы, евенты, сообщения).
Допустим, что Винда решила переключиться в основной поток после выполнения (а может, и во время выполнения) этой строчки:

И в основном потоке сокет закрывается (ну, прервалось соединение - бывает и такое). И обратно переключается уже после того, как сокет закрыт.
Соответственно, всякие обращения типа Read, дальшейшее чтение ReceiveLength и т.п. будут как минимум невалидными, а как максимум - приведут к ошибке работы с памятью.

Добавлено через 3 минуты и 22 секунды

И то - далеко не факт, что произойдет моментальное переключение на нужный поток. Например, в случае использования критических секций это гарантировать нельзя. Некоторую гарантию дает только SendMessage, которая, в частности, используется (-лась, по крайней мере в D7) в Synchronize 

тоесть Вы хотите сказать, что лучше бы было использование компонента сокета внутри потока?
хотя эти действия у меня заключены в try except и finally
за примерчик спасибо отдельное  

забыл сказать - этот код из события OnRead компонента.
Заводить поток, чтобы без перерыва читать оттуда данные, а отправлять другие данные из основного потока - нельзя.

Добавлено через 4 минуты и 29 секунд

Как минимум - создание и активация сокета в OnExecute потока.
Но в этом случае для правильной работы сокета в потоке нужно организовать цикл выборки сообщений. В том случае, если тип у сокета (свойство ClientType)- ctNonBlocking. Если выставлен ctBlocking - ничем помочь не могу, не работал с этим режимом.

А чем вызвано желание сетевой работы именно в доп.потоке?

спасибо вот это не учел. Сейчас переделаю посмотрим что получится

Это не примерчик, вот примерчик Реально использующийся уже несколько лет код, не претерпевший почти никаких изменений с тех пор 

UPD: поменял ссылку на более поздний пост.

Это сообщение отредактировал(а) kami - 11.2.2013, 21:15

Я так понимаю это всё в не блокирующем режиме? потому что в блокирующем у меня данные вообще не приходят в событии OnRead

Это сообщение отредактировал(а) Antony41 - 11.2.2013, 21:32

в блокирующем несколько другая система - там (вроде, могу ошибаться) на каждое соединение заводится отдельный поток, в котором всё и вертится. Но - он мне изначально не понравился, посему - даже не разбирался с ним. Это не значит, что блокирующий режим - плохой! Просто я не умею его готовить.

Кстати, там в примере - большой недостаток. Во всех событиях OnRead последним оператором должно быть Data.Free, иначе пойдут утечки.

Это сообщение отредактировал(а) kami - 11.2.2013, 21:41

Про сервер это так, но я имею ввиду клиента. т.е. сервер у меня в поточном режиме(blocking) а клиент впринципе тоже был в (blocking).
И вот теперь я сижу и думаю. Я понимаю что блочный режим для сервера нужен для того что бы поддерживать соединения в отдельном потоке и это нужно для того что бы сервак не зависал, НО зачем клиенту блочный режим ведь у него только одно соединение, или это нужно для поддержки соединений с несколькими серверами так что ли? В данном случае у меня один сервер и значит что мне не нужно использовать поточный режим для клиента?

можно поспорить. Я не думаю, что у Вас в коде производится настолько ресурсоемкая работа с принимаемыми/отправляемыми данными (или их настолько много принимается/отправляется за единицу времени), что это замедлит работу основного потока.
Чаще всего, "заморозка" происходит из-за неправильных алгоритмов обработки данных в неблокирующем режиме.


Один ClientSocket - одно соединение. А сделано, я думаю, чтобы использовать один и тот же подход к обработке данных. Согласитесь, нелогично было бы на клиенте ориентироваться на OnRead|OnWrite и т.п., а на сервере - использовать потоки.
"Всё должно быть единообразно - подстрижено, покрашено, посыпано песком" (с) армейское выражение.

Добавлено через 2 минуты и 41 секунду
Аргумент в пользу неблокирующего режима - создание на каждое соединение дополнительного потока считаю расточительством.
Что будет, если количество живых подключений к серверу будет в районе 1000? Вы представляете себе, как винде будет тяжко разрулить такое количество потоков?

впринципе переписал немного, получается что сервер работает в режиме blocking а клиент nonblocking, короче 

проблемка такова:
есть структура Record, и объект этой структуры GlobalData
указатель на эту структуру fData: PData


теперь заполняю структуру

и отправлять её приходится непонятным пока образом.
Вот так всё нормально принимается клинтом:

если вместо этого написать 

то отчет клиента такой:


мне вот непонятно может быть эта строка всё таки верна?


Это сообщение отредактировал(а) Antony41 - 13.2.2013, 17:29

fData указатель. SizeOf = 4(8)

Добавлено @ 17:40
Пкажи fRSDataTWinSocketStream.Write

Добавлено через 11 минут и 29 секунд


Это сообщение отредактировал(а) Чучмек - 13.2.2013, 17:41

Передаешь только первые 4 байта.
Твоя структура принимается частями. 
Каждую часть, при приеме, ты считаеш новой структурой.  

угу вот я тоже уже понял что это размер в памяти не структуры а указателя. Вот нифига не пойму

Структуры у меня одинаковы что в клиенте что на сервере
размер фиксированный у обоих как их не заполняй. вот она структура собственно


Смотрите пакет мне приходит рубленый значит потоки байт данных передаются последовательно один за другим это так?
а значит допустим событие OnRead в клиенте  может выполнится несколько раз...
А это значит мне нужно создать например MemoryStream, как глобальную переменную а при выполнении onRead писать всё в MemoryStream последовательно. Я в правильном направлении?

Как тогда мне определить начало и конец нового пакета? для того чтобы обработать принятый пакет очистить MemoryStream и начать принимать следующий пакет поток данных нового пакета?

Добавлено @ 18:10

С этим я согласен тупанул малёха, теперь делаю так 

но тут возникает вопрос чем отличается от того что выше вот это
fRSData.WriteBuffer(fData^, SizeOf(fData^));

Добавлено @ 18:15

А что показывать стандартный класс, стандартная функция))) (Delphi XE)

Это сообщение отредактировал(а) Antony41 - 13.2.2013, 18:18

Да. Я уже нашел.
Какой протокол?  TCP?

может вобще стоит перевести ClientSocket в режим блокинга

Добавлено через 6 минут и 52 секунды

ну наверно))) ведь TServerSocket/TClientSocket использует его вроде как

Добавлено через 11 минут и 54 секунды
И еще вот такой вопрос например если у меня клиент будет работать в режиме nonblocking я так понимаю это в основном потоке будут приниматься данные... Предположим что пакет принимался принимался а пользователь затем открыл какое нибудь окно ShowModal,
прием данных приостановится? если я размещу на форме компонент TidAntifreeze который собственно не относится к TClientSocket, будет ли пролжаться приём данных в таком случае?

По размеру передаваемой структуры.

Делаешь глобальными (или  свойство) буфер (размер твоей структуры) Buff
и размер данных записанных в буфер. L

В onRead,
 0. offset:=0;
 1. записываешь в буфер, с позиции L,принятые данные   c позиции offset размером count:=min(BuffSize-L,ReadLength-offset) ;
 2. L=L+count;
 3. If L=BuffSize -> Передаешь записанный буфер на обработку ; L:=0; offset:=offset+count; if offset< ReadLength then goto 1


Это сообщение отредактировал(а) Чучмек - 13.2.2013, 18:39

Жесть что попроще ни как ? может всё таки перевести клиента в режим блокинга и работать уже в потоках?

А какая разница?
Неблокирующий: пришел пакет -> событие
Блокирующий режим: пришел пакет ->поток вышел из Write.
Хоть так хоть эдак,  сколько пакетов, столько фрагментов.

Добавлено через 3 минуты и 58 секунд

Есть системный буфер. После выхода из Modal прочитаешь несколько пакетов сразу.

Это сообщение отредактировал(а) Чучмек - 13.2.2013, 18:51

Интерфейс не будет подвисать?

Добавлено через 1 минуту и 47 секунд

Тоесть они уже будут приняты останется только состыковать?

Это сообщение отредактировал(а) Antony41 - 13.2.2013, 18:56

да

ну вот смотрите вот как я сейчас всё переписал приблизительно... 
Подопните плиз в нужную сторону если что то не так.
Processing(@GlobalData); //там я уже работаю с пакетом

SIZE_OF_STRUCT это постоянный размер моей структуры
ReadedLen это кол-во прочитанных байт (глобальная Integer)
MS это TMemoryStream




Это сообщение отредактировал(а) Antony41 - 13.2.2013, 19:39

Antony41, извини сразу не ответил, был занят.
Я с TClientSocket не работал. Работал с сокетами только через API
Но чтение я бы сделал так.


Это сообщение отредактировал(а) Чучмек - 14.2.2013, 02:45

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

Вызовется несколько раз proc. Остаток (меньший, чем размер TData) ,будет хранится в выделенной памяти. Адрес  выделенной памяти хранится в связанном с сокетом указателе Data. На каждый сокет свой указатель, своя память. Это гарантирует, что при получении, данные разных соединений не будут смешиваться.
  

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

обработчик OnRead...

затем отправлю пакет на обработку, то при следующем вызове обработчика в Socket.ReceiveLength будут оставшиеся байты (990 байт) ?

Добавлено через 2 минуты и 26 секунд
тоесть если пришло 1000 байт 
а я буду читать по 1 байту
Socket.ReceiveBuf(ReadBuf, 1);

то обработчик будет вызываться 1000 раз?

Скажем так. 
Твоя структура 200 байт
Пришло 199 байт.
Событие OnRead.
Выделили память 4+200
В выделенную память записали 199 принятых байт и Integer=199
Пришло еще 399 байт
Событие OnRead.
В выделенную память дописали 1 байт
Вызвали proc, передали принятую структуру.
В выделенную память записали 200 байт
Вызвали proc, передали принятую структуру.
В выделенную память записали 198 байт и Integer=198
ждем еще.

Добавлено через 5 минут и 53 секунды
Че гадать, когда легко можно проверить.

Спасибо Вам огромное!   Вы все очень помогли и дали мне понять в чем заключалась моя ошибка, а главное разъяснили и разжевали всё надо! Пока тему не буду закрывать, возможно возникнет в ближайшие дни нерешимая без вашей помощи ситуация.

Кроме того. Если ты не используешь устойчивое соединение, можешь прочитать сразу все данные в OnDisconnect.

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


И эта строка грузит мой цп на 25% при 1 подключенном клиенте, почему так как быть?

потому что процессор четырёхядерный

ну 4 и что, его хватит только на 4 потока... и потом цп будет загружен на 100%. как быть то чтоб не такой прожерливый был? Может быстро  обрабатывать данные и выходить из потока, отключать клиента, а клиент будет слать серваку каждые например 30-40 сек команду что он на связи... серв же посчитает его отключенным только после 5 попыток поставит ему статус офлайн. А вот если выполняешь какой нибудь запрос от клиента то отсылать сразу его и если нужно соединиться например для передачи какого нибудь файла, стрима, затем снова отрубить.

Ну самое простое, но неправильное, вставить в цикл sleep(100)

ну а правильное ?

Ну вот посмотри.

Скомпилируй запусти, и введи в браузере http://localhost:3600/

Antony41, я заврался. Так тоже не годится.
Оно конечно работает, но через костыль.

Это сообщение отредактировал(а) Чучмек - 18.2.2013, 11:39

Antony41, советую разобраться с сокетами (API)
Вот как выглядит сервер на WinSock API. (без проверки ошибок)

p.s. T(Clent)ServerSocket всего лишь ООП обертка для WinSock API.

Вот тоже на TServerSocket

p.p.s При закрытии, оба варианта будут ждать, пока не разорвется соединение. Только тогда   recv/ClientSocket.ReceiveBuf вернет управление.



Это сообщение отредактировал(а) Чучмек - 18.2.2013, 16:24

Ответ один - внутри цикла нет, или не правильно используется функция ожидания.
Например. TWinSocketStream.WaitForData возвращает управление если в сокете остались непрочитанные данные.
TWinSocketStream - редкое г. Лучше не используй его. На мой взгляд - бесполезный компонент. В TWinSocketStream используются только read/write/WaitForData
Если при остановке сервера необходимо сразу остановить все потоки (ClientSocket.Connected возвращает false)-
вместо TWinSocketStream.WaitForData используй можно использовать
 
WaitForData(ClientSocket,timeout) -> true, если есть данные для чтения и false, если timeout

Это сообщение отредактировал(а) Чучмек - 18.2.2013, 16:26

Оно вобще иногда не всегда корректно работает

Спасибо Тебе за ясность! щас буду испытывать

Добавлено через 4 минуты и 6 секунд
PS по сути то я и не использую WaitForData, а использую ожидание через GetTickCount - Tick >= TIME_OUT

Да нет, должно работать.
Возвращает true, если есть данные для чтения и false, если таймаут или ошибка.
Однако если прочитано меньше чем пришло - всегда true и без ожидания.
Один байт не прочитал - и будет твой поток грузится на 100%.

кстати мне sleep(10) очень помогло впринципе засыпание на 10 мс незаметно, это ни как не влияет на приём данных... а вот в цикле с GetticCount самое оно. Загрузка ЦП при 20 подключ. клиентов составила 0-1% при опросе клиентов каждые 3 сек. Провёл тестирование подключил 20 клиентов, и они стабильно обменивались данными с сервером 7-8 часов при закрытии серва все 20 клиентов были на связи. Пока ошибок не выявил.

Это сообщение отредактировал(а) Antony41 - 18.2.2013, 16:39

Короче тут такая ситуация вышла... Я запарился с этими vcl (TClientSocket) и решил с чистого листа на Socket API впринципе пока все прекрасно...
Вопросик образовался:
Я Выполняю прием данных в основном потоке тоесть
 
пока выполняется эта функция, блокируется главный поток на время приёма данных. (ну я имею ввиду зависание интерфейса).
никакие тут ProcessMessages не помогают,
Что будет если я работу и прием данных напишу в отдельном потоке? ни каких конфликтов не возникнет при переключении потоков системой?
или что посоветуете.

Antony41, есть неблокирующий режим, есть select.

ок спс... щас поюзаем

Добавлено через 10 минут и 26 секунд
блин... чето я запутался немного.
неблокирующий сокет создает отдельный поток на каждое подключение, так не будет ди тоже самое что я буду использовать блокирующий сокет в отдельном потоке, просто создам поток и суну туда все функции работы с сокетом.?

Ребят помогите чёто не пойму как надо. Вот процедура приема данных у клиента
проблема в том что иногда структура не верно заполняется, а иногда верно.
Если проверять когда данные от сервера ушли уже точно, то пакет приходит нормально, а вот если не ушли или ушли не полностью то иногда пакет поступает в обработку (processing()) и обрабатывается не верно.

Короче серв шлет тестовый пакет каждые 5 сек, если я буду проверять пришел пакет или нет каждые 5 сек, то ошибки обработки (тут не понятно данные вроде по размеру заполнятся полностью, может там какие нибудь спец симполы в начале или конце пакета добавляются?)  
А если я буду делать проверку ReceiveNBytes каждые напр. 6-7 сек то всё ОК.  

Antony41, не выдумывай.


Добавлено через 13 минут и 52 секунды
Нажми несколько раз подряд на Button1.
Antony41,неблокирующий режим для того и существует, чтобы обойтись без дополнительных потоков.
Есть как минимум один способ на блокирующем режиме - проверять состояние сокета через  select (посмотри выше, я давал пример где проверялось подключение),
и есть несколько способов на неблокирующих.

Просто терпения нет хочется быстрее выучить и написать уже рабочую нормальную прогу...))) Пошел снова читать)))

завтра если будет время перепишу всё под неблокирующий. посмотрим что из этого выйдет.
тут я так понимаю select  timeout для recv задавать не нужно, так как прием данных будет возникать по событию FD_READ и вечного ожидания данных не будет? 

Да.
WSAAsyncSelect "привязывает" оконное сообщение к сокету(или, точнее, события сокета к оконному сообщению) и переводит сокет в асинхронный(неблокирующий) режим. Можно привязать одно или несколько событий FD_xxx. 

чот то не выходит,  
Чучмек, 

Почему так то разве если пакет придут по частям то ведь эта функция сработает не корректно, ведь у нас   buff:array[word] of ansichar; определяется каждый раз заново

короче я не пойму я уже всё сделал в одном основном потоке, сделал привязал событие FD_READ к сообщению
всё ок при отправке данных, событие возникает нормально при чём сообщение которое отправляется обрабатывается несколько раз, и приходит нужное число байт, но буфер пустой(((( как правильно принимать рубленные пакеты в асинхронном режиме а именно буфер каких нибудь байт.... блин честное слово запарился, проект пользуется спросом а я не могу тут передачу данных наладить(((Что ж всё так печально то, уже и на стандартные компоненты забил засунулся в API а толку... 

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

Ты все правильно понимаешь. Пример на неблокирующий режим и только.
Конечно, буфер для сборки пакета должен быть глобальным. Как глобально Memo1.  
Кроме того, если возможно несколько соединений одновременно - под каждый сокет должен быть свой буфер.

блин приходит пустой пакет(((( как правильно принять данные в ассинхронном режиме не блокирующем?

если поставить например вместо if iStillToReceive = 100 then, iStillToReceive = SizeOf(Buff) или 200 то данных в структуре нет, мало того еще и ошибка, а вот если сто +- то читается нормально и там те данные которые я передал

тоесть не не так, получается если я ставлю размер принимаемого буфера Buff: array [0..500] of Char; то всё пока нормально приходит 
а если поставить уже Buff: array [0..1000] of Char, то уже пустой буфер. как так

Ты ведь пакет собираешь.


Пришел  первый кусок (меньше чем указываешь в recv) -сумма меньше. Пришел второй кусок -сумма уже больше.

какого типа должен быть Buff

не работает то принимает то нет, если размер структуры больше 1000 уже не принимает

разобрался немного еще отпишусь

или

какой сервер лучше? многопоточный? синхронный асинхронный? синхронный и асинхронный это однопоточные? Могу ли я мспользовать WSAAsyncSelect в многопоточном сервере?

Добавлено через 12 минут и 1 секунду
система асинхронных сокетов прикольная и удобная. вобще мне нужно разработать так, чтобы сервер максимально быстро реагировал на входящие события сокетов и так же быстро рассылал им ответное сообщение, на данный момент, могу использовать 8 ядерный Core i7 или серверный комп

Сколько одновременных подключений ожидается?
Сколько времени будет занимать обработка данных от клиента + подготовка ответа?
Все что ниже - лишь мое мнение.
Если несколько подключений - однозначно многопоточный в блокирующем режиме (простота,распределение нагрузки по ядрам процессора, быстрота реакции)
Если большое количество подключений -  асинхронный.
Если важна максимально быстрая реакция сервера на запросы клиента или  процессорозатраты на обработку всех соединений не влезают в один поток (в производительность одного ядра), то необходим многопоточный (число потоков равно числу ядер) асинхронный.

На каждый поток должно быть свое окно со своей очередью сообщений. Соединения должны распределятся между потокам.
Окна придется создавать на WinAPI.
Или используй другой способ работы с сокетами в неблокирующем режиме.


Это сообщение отредактировал(а) Чучмек - 17.4.2013, 23:09

сейчас пытаюсь сделать так
создал класс Tserver=class (TWinControl) //окно? окно!
в нем создал слушающий serversocket, и событие WSAAsyncSelect, передающее FD_Accept в это же окно TServer

при обработке сообщения внутри тела TServer, создается дополнительный класс TConnection = class(TWinControl), и в неё заполняются все данные о подключенном сокете, далее  указатель на PConnection добавляется в список TList и связывает WSAAsyncSelect с окном TConnection
как такой подход?



Добавлено через 1 минуту и 15 секунд
получается типа многопоточности?

Добавлено через 3 минуты и 51 секунду
если учитывать что AsyncSelect переводит сокет в отдельный поток
получается при каждом подключении создается сокет и заполняется в класс TWinControl и переводится в отдельный поток, получая в свою очередь события в виде сообщений

Добавлено через 4 минуты и 36 секунд
или это не так