Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Прием данных по сокету. Какие конвенции лучше?
Форум на CrossPlatform.RU > Курилка > Алгоритмы, задачи по программированию, логические игры
Andrewshkovskii
Есть клиент и сервер. Постоянно обмениваются сообщениями разной длинны.
Сейчас, что бы понять, где кончается одно сообщение и начинается другое, используется конвенция сообщений такая :
Цитата
%длина_всего_соообщения%|%тело сообщения%


Но с этим иногда бывают косяки. Есть ли какие-то ещё конвенции или парадигмы, как лучше общаться сокетам большими сообщениями?
sidsukana
А чем тебя не устраивает обмениваться структурами?
Если у тебя клиент и сервер знают

struct Message
{
    quint32 size;
    QString msg;
};

void read()
{
    QByteArray buffer;
    // читаем первые 4 байта размер блока текста
    buffer = read(4);
    quint32 size = buffer.toUInt();

    buffer = read(size);
    QString str = buffer.data();
}


Это конечно грубо я написал. В идеале лучше создать экземпляр сериализатора данных и через него записывать в сокет и из него же получать.
kuzulis
Цитата
Есть ли какие-то ещё конвенции или парадигмы, как лучше общаться сокетам большими сообщениями?


man это и это

Обычно "парадигмы" это запрос/ответ или посылка/подтверждение.

Структуры кадров в общем случае выглядят: <header><body><trailer>

Где header, body, trailer - это поля кадра.

в header, например, могут указываться маркёры + биты направлений + биты типа пакета (первый/не первый/последний) + номер пакета + длина последующих данных body
в body собственно, данные.
в trailer, например, могут указываться маркёры + CRC

Если сообщение уж оч длинное, то можешь разбить свою "подпрограмму" обработки сообщений на два ISO/ISI уровня: грубо канальный + приложения.

Твое приложение будет принимать готовое здоровенное сообщение из уровня приложения и писать в уровень приложения.
Уровень приложения принимает от здоровенное сообщение от программы, дробит его на части, и отсылает канальному(или физическому - пофик как назовешь), который оборачивает в <header><body><trailer>
и шлет в сокет с обязательным ожиданием ACK от удаленной стороны.
И так до конца, пока Уровень приложения не передаст все части этого сообщения.

В обратку - канальный уровень из сокета принимает кусок данных как <header><body><trailer>, проверяет header, trailer . Если все ОК,
то он обрезает header, trailer, вынимает кусок body и передает его наверх в Уровень приложения. Если какая-то хрень с header, trailer,
то канальный уровень перезапрашивает этот кусок.
Уровень приложения принимает body от канального, и для уровня приложения этот же body будет выглядеть как <header2><body2><trailer2>
оно это проверяет, извлекает body2 и накапливает эти куски в своем буфере (добавляет каждый следующий кусок). И когда Уровень приложения
примет от канального <header2><body2><trailer2> с указанным в header2 флагом о том, что это последний кусок - то
Уровень приложения добавляет этот кусок в свой буфер и возвращает этот буфер приложению. Этот буфер и будет сообщением.

Ведь нисколечки не сложно? Правда ведь? :rolleyes:

Можешь посмотреть тут , оч познавательная статья.
Можешь адаптировать для себя например протокол X-Modem или еще что нить.

Это если тебе нужна надежность!!!
ssoft
Цитата(Andrewshkovskii @ 8.12.2011, 12:03) *
Но с этим иногда бывают косяки.


Что за косяки?
Пока не сталкивался. Очень хотелось бы узнать.

Andrewshkovskii
Цитата(kuzulis @ 8.12.2011, 12:17) *
Цитата
Есть ли какие-то ещё конвенции или парадигмы, как лучше общаться сокетам большими сообщениями?


man это и это

Обычно "парадигмы" это запрос/ответ или посылка/подтверждение.

Структуры кадров в общем случае выглядят: <header><body><trailer>

Где header, body, trailer - это поля кадра.

в header, например, могут указываться маркёры + биты направлений + биты типа пакета (первый/не первый/последний) + номер пакета + длина последующих данных body
в body собственно, данные.
в trailer, например, могут указываться маркёры + CRC

Если сообщение уж оч длинное, то можешь разбить свою "подпрограмму" обработки сообщений на два ISO/ISI уровня: грубо канальный + приложения.

Твое приложение будет принимать готовое здоровенное сообщение из уровня приложения и писать в уровень приложения.
Уровень приложения принимает от здоровенное сообщение от программы, дробит его на части, и отсылает канальному(или физическому - пофик как назовешь), который оборачивает в <header><body><trailer>
и шлет в сокет с обязательным ожиданием ACK от удаленной стороны.
И так до конца, пока Уровень приложения не передаст все части этого сообщения.

В обратку - канальный уровень из сокета принимает кусок данных как <header><body><trailer>, проверяет header, trailer . Если все ОК,
то он обрезает header, trailer, вынимает кусок body и передает его наверх в Уровень приложения. Если какая-то хрень с header, trailer,
то канальный уровень перезапрашивает этот кусок.
Уровень приложения принимает body от канального, и для уровня приложения этот же body будет выглядеть как <header2><body2><trailer2>
оно это проверяет, извлекает body2 и накапливает эти куски в своем буфере (добавляет каждый следующий кусок). И когда Уровень приложения
примет от канального <header2><body2><trailer2> с указанным в header2 флагом о том, что это последний кусок - то
Уровень приложения добавляет этот кусок в свой буфер и возвращает этот буфер приложению. Этот буфер и будет сообщением.

Ведь нисколечки не сложно? Правда ведь? :rolleyes:

Можешь посмотреть тут , оч познавательная статья.
Можешь адаптировать для себя например протокол X-Modem или еще что нить.

Это если тебе нужна надежность!!!

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

Косяки в производителельности таких алгоритмов разбора сообщения - операции со строками в основном.
kuzulis
Цитата
Я вроде говорил о том, что над протоколом, а не внутри. Зачем Вы мне все это написали?

Я тебе и написал про "НАД".

Цитата
Я не протокол пишу, а пытаюсь понять - как лучше передавать сообщения между сокетами, что бы соблюдалась целостность при передаче данных кусками (именно так оно работает в реальности).

Я тебе написал как. Если не понимаешь - то брось это дело.
Без некоего протокола передачи - у тебя ничего не получится. Бросай в общем..
ssoft
Цитата(Andrewshkovskii @ 8.12.2011, 15:05) *
Косяки в производителельности таких алгоритмов разбора сообщения - операции со строками в основном.


Здесь есть пример сборки сообщения из сокета.
сборка сообщения
Никаких операций со строками производить не нужно.
С одной стороны отправил QByteArray, с другой получил.
Andrewshkovskii
Цитата(kuzulis @ 8.12.2011, 14:43) *
Цитата
Я вроде говорил о том, что над протоколом, а не внутри. Зачем Вы мне все это написали?

Я тебе и написал про "НАД".

Цитата
Я не протокол пишу, а пытаюсь понять - как лучше передавать сообщения между сокетами, что бы соблюдалась целостность при передаче данных кусками (именно так оно работает в реальности).

Я тебе написал как. Если не понимаешь - то брось это дело.
Без некоего протокола передачи - у тебя ничего не получится. Бросай в общем..

Не брошу.

Цитата(ssoft @ 8.12.2011, 15:43) *
Цитата(Andrewshkovskii @ 8.12.2011, 15:05) *
Косяки в производителельности таких алгоритмов разбора сообщения - операции со строками в основном.


Здесь есть пример сборки сообщения из сокета.
сборка сообщения
Никаких операций со строками производить не нужно.
С одной стороны отправил QByteArray, с другой получил.

Дело в том, что я все это для питона собираю - там я использую строки и сериализованный json, а не bytearray.
Кстати, вот код, если кому интересно :
def on_ready_read(self):
        data = str(self.readAll())
        while data:
            if not self.wait_len and '|' in data:#new data and new message
                    self.wait_len , data = data.split('|',1)
                    if match('[0-9]+', self.wait_len) and (len(self.wait_len) <= MAX_WAIT_LEN) and data[0]=='{':#okay, this is normal length
                        self.wait_len = int(self.wait_len)
                        self.temp = data[:self.wait_len]
                        data = data[self.wait_len:]
                    else:#oh, it was crap
                        self.wait_len , self.temp = '',''
                        return
            elif self.wait_len:#okay, not new message, appending
                self.temp+=data[:(self.wait_len-len(self.temp))]
                data=data[len(self.temp):]
            elif not self.wait_len and not '|' in data:#crap
                return
            if self.wait_len and self.wait_len == len(self.temp):#okay, full message
                    self.data_ready.emit(self.temp)
                    self.wait_len ,self.temp = '',''
                    if not data:
                        return
Влад
Цитата(Andrewshkovskii @ 8.12.2011, 12:03) *
Но с этим иногда бывают косяки. Есть ли какие-то ещё конвенции или парадигмы, как лучше общаться сокетам большими сообщениями?

А какой протокол используется у тебя на транспортном уровне?
Andrewshkovskii
Цитата(Влад @ 9.12.2011, 15:45) *
Цитата(Andrewshkovskii @ 8.12.2011, 12:03) *
Но с этим иногда бывают косяки. Есть ли какие-то ещё конвенции или парадигмы, как лучше общаться сокетам большими сообщениями?

А какой протокол используется у тебя на транспортном уровне?

TCP. В общем, косяк был в алгоритме , я его переписал. Пока всё ок , но есть проблемы, когда пакеты теряются. Тогда, конечно, алгоритму беда.
Влад
Гмм. Что-то это из категории загадок.... :-)

Во-первых, в TCP нет никаких "пакетов" - т.к. это потоковый протокол передачи данных. Во-вторых, крайне удивительно, что "пакеты теряются" - т.к. это протокол с гарантированной доставкой.

Думаю, что нужно заниматься поиском багов в прикладном уровне.
Andrewshkovskii
Цитата(Влад @ 10.12.2011, 19:19) *
Гмм. Что-то это из категории загадок.... :-)

Во-первых, в TCP нет никаких "пакетов" - т.к. это потоковый протокол передачи данных. Во-вторых, крайне удивительно, что "пакеты теряются" - т.к. это протокол с гарантированной доставкой.

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

А поток из чего состоит?
Т.е. Вы утверждаете, что используя TCP/IP протокол - вы никогда не потеряете фрейм с данными?Никогда-никогда? Ни при каких условиях?
Вся это гарантированная доставка для сферического коня в вакууме. Не забывайте оборудование - которое может сбоить, кабеля повреждаться и т.п..
И в догонку:
Цитата
TCP обеспечивает надёжную непрерывную передачу данных, исключающую потерю данных или нарушение порядка их поступления или дублирования, может перераспределять данные, разбивая большие порции данных на фрагменты и наоборот склеивая фрагменты в один пакет.

Ок, я не правильно назвал пакеты - порциями, тут я не прав. Суть была в том, что порция данных может потеряться, тупо оборудование засбоит и всё - не получите вы свой кусочек. Или какой-нибудь софт, вроде FW заблочит.
BRE
Цитата(Andrewshkovskii @ 10.12.2011, 23:42) *
Суть была в том, что порция данных может потеряться, тупо оборудование засбоит и всё - не получите вы свой кусочек. Или какой-нибудь софт, вроде FW заблочит.

Нет, порция потеряться не может. Стек контролирует порядок получения пакетов и если необходимо, будет запрашивать пакет заново.
Пока он этот пакет не получит, дальше он ничего отдавать не будет. Программа никогда не получит данные из сокета с "дыркой" посредине.

Andrewshkovskii
Т.е. , если я передаю файл, скажем, 1 гб, и где-то оборудование сдохнет - я не получу ни байта от этого потока?
Я так понимаю, я получу всё до момента сбоя - а это уже фейл и провал для предложенного алгоритма.
BRE
Если пакет теряется - стек будет просить его перепослать. Если при этом удаленная машина перестанет отвечать, то ты получишь ошибку.
Влад
А если ты эту ошибку не обрабатываешь, то это баг в логике прикладного уровня.... Логика прикладного уровня должна быть готова к тому, что TCP соединение может в любой момент разорваться по независящим от локального хоста причинам.

(С коллегой BRE я бы поспорил только в отношении терминологии: то, что он называет "пакетом", я склонен называть "сегментом данных". :-) )
BRE
Цитата(Влад @ 11.12.2011, 14:05) *
(С коллегой BRE я бы поспорил только в отношении терминологии: то, что он называет "пакетом", я склонен называть "сегментом данных". :-) )

Со мной конечно можно поспорить, но в RFC793 так же частенько проскакивает так называемый "пакет", а с ним (с RFC793) спорить сложнее. ;)
Andrewshkovskii
Сообщение перемещено Сюда
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.