"Склеивание" сообщений ТСР |
Здравствуйте, гость ( Вход | Регистрация )
"Склеивание" сообщений ТСР |
pwp2008 |
19.10.2015, 19:31
Сообщение
#1
|
Студент Группа: Участник Сообщений: 29 Регистрация: 19.12.2014 Пользователь №: 4299 Спасибо сказали: 0 раз(а) Репутация: 0 |
Подскажите пож-та, встречалось ли Вам отправленные друг за другом сообщения (клиентом) получать в сервере "склееном" виде, как если бы это было одно сообщение. В чем причина такой работы по протоколу TCP\IP ? Разрулить эту проблему удалось несколько искусственным способом, хотя здесь может подойти и передача длины сообщения и/или контрольный суммы. Видимо так склеены могут быть не 2, а даже больше последовательных сообщений.
|
|
|
ViGOur |
26.10.2015, 17:17
Сообщение
#2
|
Мастер Группа: Модератор Сообщений: 3296 Регистрация: 9.10.2007 Из: Москва Пользователь №: 4 Спасибо сказали: 231 раз(а) Репутация: 40 |
pwp2008, вот ты упрямец! Перечитай заново, что я описал выше.
Таймауты тебе могут помочь в том случае, если сервер или клиент не заняты, но если один из них занят (I\O операции или по процессору) то всеравно будет склейка и тайм ауты не помогут. Это из серии я надеюсь всё будет в порядке, но в программировании это не допустимо, потому нужно создавать условия, чтобы всё было в порядке. |
|
|
pwp2008 |
26.10.2015, 19:49
Сообщение
#3
|
Студент Группа: Участник Сообщений: 29 Регистрация: 19.12.2014 Пользователь №: 4299 Спасибо сказали: 0 раз(а) Репутация: 0 |
pwp2008, вот ты упрямец! Перечитай заново, что я описал выше. Не упрямый, а просто - неграмотный. Стаж по диалогу в TCP у меня небольшой, может год- полтора, на 2х или 3х приложениях, просто я ни разу до текущего приложения не попадал с такие ситуации("склеивание\разрезание"). Это, конечно, не довод. Но от всей этой ситуации повеяло безнадежностью : Цитата(ViGOur) Обычно, чтобы всегда были идеальные условия используют структуру приведенную мной выше, по следующей схеме: 1. При поступленни данных читаем первые 4 байта, и приводим их к int, чтобы получить размер буфера. 2. Читаются столько байт, сколько указанно в первых четырех байтах полученных в 1 пункте. 3. Что-то там делаем с полученными данными. 4. Переходим к 1 пункту. Т.е. 4 байта уж точно не разрежутся ? Вообще, можно и 2-мя обойтись, надежней. Сколько ждать полного буфера, длина, которого была заявлена в заголовке, ведь можем и не дождаться? Надеюсь, что ТСР не переставит блоки, а будет все-таки давать их в порядке отправления. Контрольная сумма меня особенно радует. Что ж, видимо с этим придется жить... Спасибо за помощь. Есть такой протокол - МЭК 104. Похоже нужно от него брать ряд идей. |
|
|
Влад |
27.10.2015, 10:33
Сообщение
#4
|
Участник Группа: Участник Сообщений: 146 Регистрация: 20.3.2009 Из: Санкт-Петербург Пользователь №: 627 Спасибо сказали: 46 раз(а) Репутация: 8 |
Т.е. 4 байта уж точно не разрежутся ? Вообще, можно и 2-мя обойтись, надежней. Сколько ждать полного буфера, длина, которого была заявлена в заголовке, ведь можем и не дождаться? Надеюсь, что ТСР не переставит блоки, а будет все-таки давать их в порядке отправления. Контрольная сумма меня особенно радует. Разрежутся или нет четыре байта длины - никто тебе не даст никаких гарантий. Да это и не имеет значения. Просто вычитывай из сокета, пока не наберутся в начале посылки эти четыре байта. А потом вычитывай столько байтов, сколько заявлено в заголовке. Либо они дойдут, либо ты получишь ошибку связи и должен на нее как-то отреагировать. Да, TCP не переставит блоки, в этом можно быть уверенным. |
|
|
Текстовая версия | Сейчас: 29.3.2024, 9:05 |