Сообщение Re[20]: Максимальная длина TCP пакета в сети от 14.02.2020 18:27
Изменено 15.02.2020 5:58 AlexGin
Re[20]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Sinclair, Вы писали:
S>Смотрите, есть протокол IP. Просто отправляем датаграммы.
Да, я в курсе. Есть.
S>Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.
Да — ping a.b.c.d — это всё Internet Control Message Protocol.
S>Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.
Да, я в курсе (уже не первый год). Это называют ориентированный_на_соединение_протокол.
Что совсем не отменяет принцип "доверяй, но проверяй". Так, то же контрольное суммирование имеется на разных уровня.
Не нужно надеяться что умный дядька всё за меня сделал.
Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
я понадеялся на приём полного блока данных. Ну вполне логично же...
Но — тут такой вот нежданчик...
Теперь — в начале блока пишу длину и делаю накопление.
После этого стало нормально.
S>Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".
Да, какие-то элементы протокола будут дублироваться на прикладном уровне.
Тем более, что следует учитывать разных вариантов реализаций взаимодействия и способов (асинхронный/синхронный).
Так, например, можно иметь асинхронный способ (сообщения), а можно и старый-добрый синхронный (типа send/recv) вынести в отдельный поток выполнения.
AG>>Файловый ввод-вывод также поддерживает потоки.
AG>>Так почему нам, вместо документа на 20 килобайт, не залепить 4-ГБ видео?
S>Я ваш вопрос не вполне понимаю.
Ну так файловые операции ведь также:
1) Не используют всё время всю производительность файловой системы;
2) Действия верхнего и нижнего уровня — зачастую в чём-то дублируют друг друга.
P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя —
и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).
S>Смотрите, есть протокол IP. Просто отправляем датаграммы.
Да, я в курсе. Есть.
S>Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.
Да — ping a.b.c.d — это всё Internet Control Message Protocol.
S>Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.
Да, я в курсе (уже не первый год). Это называют ориентированный_на_соединение_протокол.
Что совсем не отменяет принцип "доверяй, но проверяй". Так, то же контрольное суммирование имеется на разных уровня.
Не нужно надеяться что умный дядька всё за меня сделал.
Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
я понадеялся на приём полного блока данных. Ну вполне логично же...
Но — тут такой вот нежданчик...
Теперь — в начале блока пишу длину и делаю накопление.
После этого стало нормально.
S>Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".
Да, какие-то элементы протокола будут дублироваться на прикладном уровне.
Тем более, что следует учитывать разных вариантов реализаций взаимодействия и способов (асинхронный/синхронный).
Так, например, можно иметь асинхронный способ (сообщения), а можно и старый-добрый синхронный (типа send/recv) вынести в отдельный поток выполнения.
AG>>Файловый ввод-вывод также поддерживает потоки.
AG>>Так почему нам, вместо документа на 20 килобайт, не залепить 4-ГБ видео?
S>Я ваш вопрос не вполне понимаю.
Ну так файловые операции ведь также:
1) Не используют всё время всю производительность файловой системы;
2) Действия верхнего и нижнего уровня — зачастую в чём-то дублируют друг друга.
P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя —
и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).
Re[20]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Sinclair, Вы писали:
S>Смотрите, есть протокол IP. Просто отправляем датаграммы.
Да, я в курсе. Есть. Это как-бы этажём ниже (по 7-ми уровневой модели OSI).
S>Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.
Да — ping a.b.c.d — это всё Internet Control Message Protocol.
S>Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.
Да, я в курсе (уже не первый год). Это называют ориентированный_на_соединение_протокол.
Что совсем не отменяет принцип "доверяй, но проверяй". Так, то же контрольное суммирование имеется на разных уровня.
Не нужно надеяться что умный дядька всё за меня сделал.
Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
я понадеялся на приём полного блока данных. Ну вполне логично же...
Но — тут такой вот нежданчик...
Теперь — в начале блока пишу длину и делаю накопление.
После этого стало нормально.
S>Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".
Да, какие-то элементы протокола будут дублироваться на прикладном уровне.
Тем более, что следует учитывать разных вариантов реализаций взаимодействия и способов (асинхронный/синхронный).
Так, например, можно иметь асинхронный способ (сообщения), а можно и старый-добрый синхронный (типа send/recv) вынести в отдельный поток выполнения.
AG>>Файловый ввод-вывод также поддерживает потоки.
AG>>Так почему нам, вместо документа на 20 килобайт, не залепить 4-ГБ видео?
S>Я ваш вопрос не вполне понимаю.
Ну так файловые операции ведь также:
1) Не используют всё время всю производительность файловой системы;
2) Действия верхнего и нижнего уровня — зачастую в чём-то дублируют друг друга.
P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя —
и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).
S>Смотрите, есть протокол IP. Просто отправляем датаграммы.
Да, я в курсе. Есть. Это как-бы этажём ниже (по 7-ми уровневой модели OSI).
S>Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.
Да — ping a.b.c.d — это всё Internet Control Message Protocol.
S>Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.
Да, я в курсе (уже не первый год). Это называют ориентированный_на_соединение_протокол.
Что совсем не отменяет принцип "доверяй, но проверяй". Так, то же контрольное суммирование имеется на разных уровня.
Не нужно надеяться что умный дядька всё за меня сделал.
Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
я понадеялся на приём полного блока данных. Ну вполне логично же...
Но — тут такой вот нежданчик...
Теперь — в начале блока пишу длину и делаю накопление.
После этого стало нормально.
S>Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".
Да, какие-то элементы протокола будут дублироваться на прикладном уровне.
Тем более, что следует учитывать разных вариантов реализаций взаимодействия и способов (асинхронный/синхронный).
Так, например, можно иметь асинхронный способ (сообщения), а можно и старый-добрый синхронный (типа send/recv) вынести в отдельный поток выполнения.
AG>>Файловый ввод-вывод также поддерживает потоки.
AG>>Так почему нам, вместо документа на 20 килобайт, не залепить 4-ГБ видео?
S>Я ваш вопрос не вполне понимаю.
Ну так файловые операции ведь также:
1) Не используют всё время всю производительность файловой системы;
2) Действия верхнего и нижнего уровня — зачастую в чём-то дублируют друг друга.
P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя —
и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).