|
PureBasic Мощный кросс-платформенный язык среднего уровня на основе BASIC. Подходит для решения широкого круга задач. |
19.07.2012, 00:26
|
#16
|
|
Ответ: Непонятки с TCP/IP
Сообщение от Dstalk
Уверен. А вот эта строчка выдает ошибку, но принудительно читает пакет, вместе с возможными кусками последующих пакетов. Этой строчки вообще не будет, если проблема перестанет проявлятся.
А выдает TCPlength.i=PeekL(*TCPBuffer) больше тысячи, потому что в памяти находится первые четыре байта пакета, а там символы, если считать их из памяти как integer, всегда получается больше 1000. Это типа проверка на ошибку пакета...
Да, и по идее, у нормальных пакетов длина всегда меньше 1000.
Забыл сказать - пакеты отправляю прогой на Blitz3D, пробовал двумя способами:
;1 способ
WriteString streamIP,msg1$
;2 способ
WriteInt streamIP,Len(msg1$)+2
WriteLine streamIP,msg1$
Оба способа дают одинаковые результаты...
|
а где уверенность что блиц это кладёт в ОДИН TCP ПАКЕТ ? TCP пакетный протокол (когда udp - дейтаграммный), и в нём гарантируется прием в точно такой же последовательности как была произведена передача
|
|
|
19.07.2012, 01:37
|
#17
|
Разработчик
Регистрация: 27.06.2009
Адрес: Рязань-Москва
Сообщений: 471
Написано 401 полезных сообщений (для 1,072 пользователей)
|
Ответ: Непонятки с TCP/IP
Пакетный? TCP насколько я помню - непрерывный поток данных, не подразделяющийся на пакеты. Пакетами в данном случае я называю отдельные сообщения в TCP потоке... Как я писал выше оба способа дают одинаковый результат.
|
(Offline)
|
|
19.07.2012, 02:07
|
#18
|
.
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений (для 6,863 пользователей)
|
Ответ: Непонятки с TCP/IP
TCP - это поток данных. Протокол может разбивать данные на сегменты, либо наоборот на уровне протокола в системе ждать пока не будет достаточно данных для полного сегмента (Нагглэ Алгоритм).
Тут дело не с протоколом, а с блицем, и не тем как он кладёт всё в кучу или наоборот, а в том что видимо число порой не отправляется последовательно. Блиц старик, и я бы не юзал стандартный функционал для сети (снова).
|
(Offline)
|
|
19.07.2012, 10:29
|
#19
|
Мастер
Регистрация: 19.03.2007
Сообщений: 1,039
Написано 153 полезных сообщений (для 252 пользователей)
|
Ответ: Непонятки с TCP/IP
доверяй wireshark-у юный падаван
советы его мудры, око его всевидяще
и да прибудет с тобой сила
|
(Offline)
|
|
Сообщение было полезно следующим пользователям:
|
|
19.07.2012, 10:55
|
#20
|
Зануда с интернетом
Регистрация: 04.09.2005
Сообщений: 14,014
Написано 6,798 полезных сообщений (для 20,935 пользователей)
|
Ответ: Непонятки с TCP/IP
Сообщение от MoKa
Блиц возможно применяет собственный алгоритм склеивания сообщений, тем самым если слишком часто отсылать, может клеить стринги вместе.
|
Я что-то не очень понял. Разделители типа EOL между строками никуда не денутся. А дейтаграммы и на уровне движка, и на уровне tcp всегда стремятся склеится (лучше отправить 1 раз 500 байт, чем два раза по 250). Функции запроса конкретного типа данных (типа ReadLine) очевидно работают в блокирующем режиме (дожидаясь приёма объекта целиком) с крахом по таймауту, задаваемому функцией TCPTimeouts.
тред не читал @ сразу овтечал
__________________
http://nabatchikov.com
Мир нужно делать лучше и чище. Иначе, зачем мы живем? tormoz
А я растила сына на преданьях
о принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест?
|
(Offline)
|
|
19.07.2012, 14:20
|
#21
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Сообщение от Dstalk
Вот код:
ReceiveNetworkData(TCPclientID,*TCPBuffer,4)
TCPlength.i=PeekL(*TCPBuffer)
If TCPlength>1000:TCPlength=1000:PrintN("Packet error!"):EndIf
ReceiveNetworkData(TCPclientID,*TCPBuffer,TCPlength)
TCPPacket=PeekS(*TCPBuffer)
Сколько тестил - он всегда(!) читает сообщение необходимой длины, не больше и не меньше. Но очень редко TCPlength захватывает 4 байта самого сообщения. Просто integer куда-то пропадает...
В этом коде еще нет проверки на то, если сообщение пришло не полностью, но когда на одном компьютере тестишь - это проблем не вызывает, проверял.
|
Я вообще удивляюсь что работает.
Где гарантия что первый вызов ReceiveNetworkData() запишет в буфер именно 4 байта? А если пришло только, скажем, 2 байта, что тогда?
Где гарантия что второй вызов функции, поместить в буфер именно столько байт, сколько указанно в TCPlength?
Может на момент чтения еще не все данные пришли, вот и будет выше описанный баг.
Если хотите чтобы все работало без сбоев, делайте следующим образом:
Заведите буфер, размером в несколько раз больше чем максимальный размер пакета.
Читайте данные в этот буфер и анализируйте сколько байт реально было прочитано функцией ReceiveNetworkData().
Если меньше положенного, то ждите и через время опять читайте, помещая результат в конец буфера.
Как только приняли все данные, тогда обрабатываете.
Буфер очищаете и опять в него пишите принимаемые данные.
|
(Offline)
|
|
19.07.2012, 14:52
|
#22
|
Разработчик
Регистрация: 27.06.2009
Адрес: Рязань-Москва
Сообщений: 471
Написано 401 полезных сообщений (для 1,072 пользователей)
|
Ответ: Непонятки с TCP/IP
Плин, опять... Как я уже выше писал - еще нет проверки на неполность пакета. Тем не менее, он всегда работает как надо! За последние два месяца это было проверено несколько десятков тысяч раз.
Сообщение от Пётр
Где гарантия что второй вызов функции, поместить в буфер именно столько байт, сколько указанно в TCPlength? Может на момент чтения еще не все данные пришли, вот и будет выше описанный баг.
|
Если на момент чтения не все данные пришли, и это я тоже писал выше, он бы считал середину следующего пакета. Такого никогда не происходило. Этот баг проявляется именно в пропаже четырех байт integer`а и очень редко. Скорее всего все-таки блитц виноват.
Прежде чем отвечать, внимательно прочитайте предыдущие сообщения в треде. Спасибо.
|
(Offline)
|
|
19.07.2012, 16:24
|
#23
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Ну смотрите дело ваше.
Я сталкивался с подобным и выше описал как решил проблему.
В таком варианте как сейчас, есть вероятность глюков из-за приема не всех данных пакета.
|
(Offline)
|
|
20.07.2012, 12:18
|
#24
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Кстати, вот один из сценариев пропадания первых 4-ёх байт пакета.
Пакеты отправляются друг за другом и возникает такая ситуация что первые 4 байта нового пакета принимаются с предыдущим пакетом.
Как бороться с этим, описал выше.
|
(Offline)
|
|
20.07.2012, 12:24
|
#25
|
Разработчик
Регистрация: 27.06.2009
Адрес: Рязань-Москва
Сообщений: 471
Написано 401 полезных сообщений (для 1,072 пользователей)
|
Ответ: Непонятки с TCP/IP
это я тоже проверял, пакет принимается ровно столько, сколько нужно - лишнее не захватывает. А вот как 4 байта эти пропадают, тогда уже прога не знает сколько байт считать и получается может захватить последующие пакеты...
|
(Offline)
|
|
20.07.2012, 14:02
|
#26
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Сообщение от Dstalk
это я тоже проверял
|
Как проверял?
|
(Offline)
|
|
20.07.2012, 14:09
|
#27
|
Разработчик
Регистрация: 27.06.2009
Адрес: Рязань-Москва
Сообщений: 471
Написано 401 полезных сообщений (для 1,072 пользователей)
|
Ответ: Непонятки с TCP/IP
логи отправленных и принятых данных, сравнивал, анализировал
Я уже в этом треде раз 5 написал, что код работает абсолютно нормально. Но очень редко и рандомно пропадают именно 4 байта, других ошибок и багов никогда не было. Пётр, извини конечно, но внимательнее читай тему...
|
(Offline)
|
|
20.07.2012, 14:29
|
#28
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Сообщение от Dstalk
логи отправленных и принятых данных, сравнивал, анализировал
|
Мне это ни о чем не говорит. Код записи в логи в студию.
Ну или как альтернатива, гадание на кофейной гуще, раз кода нет.
Сообщение от Dstalk
Пётр, извини конечно, но внимательнее читай тему...
|
Зачем тогда была создана эта тема если не пытаешься услышать других?
Кому нужно избавится от глюков в проге, мне или тебе?
Я тебе уже несколько раз писал чтобы проверял сколько реально было прочитано байт, но видимо ты невнимательно читаешь.
|
(Offline)
|
|
20.07.2012, 15:24
|
#29
|
Разработчик
Регистрация: 27.06.2009
Адрес: Рязань-Москва
Сообщений: 471
Написано 401 полезных сообщений (для 1,072 пользователей)
|
Ответ: Непонятки с TCP/IP
не?)) Практически тоже самое при отправке сообщения.
Ты мне не веришь что других ошибок не возникало, кроме пропажи integer`а. Ну извини, логи у меня выводятся в консоль, и я их не сохраняю.
Предпологалось, что последнее сообщение было на первой странице треда, где я поблагодарил MoKa.
Глюков в программе нет, единственное что нужно проверку на неполность сообщения, но это я и сразу знал, и писал об этом.
Подправил кстати TCPPacket=PeekS(*TCPBuffer,TCPlength) строчку в коде на первой странице, на прием никак не влияет, но в стринг TCPPacket могут записатся куски старых пакетов из буффера, так как он не очищается...
Закрыть бы темку, а то ничего кроме срача тут не предвидится...
|
(Offline)
|
|
20.07.2012, 15:48
|
#30
|
Нуждающийся
Регистрация: 23.05.2007
Сообщений: 95
Написано 34 полезных сообщений (для 53 пользователей)
|
Ответ: Непонятки с TCP/IP
Сообщение от Dstalk
|
Конечно не! Вот как должно быть.
RealCountBytes_1 = ReceiveNetworkData(TCPclientID,*TCPBuffer,4)
TCPlength.i=PeekL(*TCPBuffer)
If TCPlength>1000:TCPlength=1000:PrintN("Packet error!"):EndIf
RealCountBytes_2 = ReceiveNetworkData(TCPclientID,*TCPBuffer,TCPlength)
TCPPacket=PeekS(*TCPBuffer)
PrintN(Str(RealCountBytes_1)+" "+Str(RealCountBytes_2))
Теперь точно покажет сколько байт было принято. И я думаю что при возникновении глюка оно будет не таким как ты предполагаешь.
Сообщение от Dstalk
Закрыть бы темку, а то ничего кроме срача тут не предвидится...
|
Раз ты не слушаешь тех, кто уже сталкивался с подобным и старается тебе помочь, то пожалуй да, тему нужно закрыть. Раз тебе помощь не нужна, то зачем вообще создавал тему?
Не выйдет из тебя программиста. Нет логического мышления и не слушаешь тех, кто старается тебе помочь!
|
(Offline)
|
|
Ваши права в разделе
|
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 22:09.
|