Сообщение Re[4]: Максимальная длина TCP пакета в сети от 10.02.2020 15:52
Изменено 10.02.2020 15:54 AlexGin
Re[4]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Stanislav V. Zudin, Вы писали:
SVZ>Я подозреваю, ты немного о другой разбивке.
SVZ>Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Да, передавать полный размер в нвчале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
SVZ>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано.
SVZ>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
SVZ>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
SVZ>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
Вот это интересно.
Где подробнее об этом почитать? Какие ключевые слова гуглить?
Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?
SVZ>Я подозреваю, ты немного о другой разбивке.
SVZ>Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Да, передавать полный размер в нвчале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
SVZ>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано.
SVZ>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
SVZ>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
SVZ>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
Вот это интересно.
Где подробнее об этом почитать? Какие ключевые слова гуглить?
Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?
Re[4]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Stanislav V. Zudin, Вы писали:
SVZ>Я подозреваю, ты немного о другой разбивке.
SVZ>Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Да, передавать полный размер в начале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
SVZ>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано.
SVZ>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
SVZ>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
А какие это значения?
SVZ>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
Вот это интересно.
Где подробнее об этом почитать? Какие ключевые слова гуглить?
Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?
SVZ>Я подозреваю, ты немного о другой разбивке.
SVZ>Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Да, передавать полный размер в начале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
SVZ>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано.
SVZ>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
SVZ>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
А какие это значения?
SVZ>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
Вот это интересно.
Где подробнее об этом почитать? Какие ключевые слова гуглить?
Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?