Для раутеров всё совсем не так, чем толще, тем больше специфика. Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.
И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями.
Он менялся несколько раз в ключевых подсистемах.
В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11.
Ага, мы-то знаем, что такое PDP endian :)) У PDP-11 сам LE заметно маскировался восьмеричными форматами для человека, и плотным упором на 16-битные значения. Что там слегка "под капотом" LE, тогда, конечно, знали, но прямого внимания не было, в отличие от x86, где уже на уровне машкодов побайтное представление давало, что LE просто бросалось в глаза, как сердитая кошка.
но определённо сыграли такую роль
Обсуждаемый RISC-V как раз действует по принципу "всё, о чём у нас нет своего твёрдого мнения, делаем, как в x86". Это хорошо видно по, например, организации виртуальной памяти.
Это если они влезают в монитор. Вероятно, у вас 200% зрение. У меня оно "так себе", и я не могу поместить в один экран на постоянную, чтобы работать с ним, более, условно, 30 строк. Конечно, кто-то вспомнит "дядюшку Боба", но функции с блоками на 50-100-200 строк реально бывают, хоть и мало. И вот тут оказывается, что, особенно когда у тебя одновременно закрывается несколько блоков, найти, где они начались - уже квест.
А с языком, где {} (и тем более они обязательны - Go, Rust, много других современных; или C/C++ с форсированной политикой всегда делать блоки, как я всем рекомендую) - перейти к парной скобке это тривиально.
А ещё, когда ты вставляешь блок кода из другого места, IDE с Питоном очень часто ошибается в выборе нужного отступа. Имея же скобки {} или хотя бы then-end, else-end, do-end, etc., такой проблемы никогда не будет.
Поэтому я при прочих равных против выделения отступами и за обязательные скобки блоков кода (лучше символами {}, но и словами тоже пойдёт).
в функциях ты просто физически ощущаешь локальное пространство имен.
И снова - если вся функция влезла в экран. Причём со всеми вложенными, если там есть замыкания.
Кодер быстро приходит к тому что вложенности >2 быть не должно, и язык старательно этому учит.
Ага, тогда вложенность переносится в создание иначе нахер никому не нужных функций с отдельными именами. Причём если в каком-нибудь C++ можно их помечать inline и компилятор тогда их усиленно встроит, в Python это приводит к замедлению "на ровном месте".
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
Да, я в курсе про YAML (не знаю, зачем вы вспомнили TOML). У него, по сути, те же проблемы -это если не считать того, что формат и в других аспектах чудовищно сложен и запутан - так что он скорее контрпример. JSON с некоторыми облегчениями типа финальной запятой и комментариями, и принудительным форматированием тут был бы полезнее.
Это крайне странное утверждение, учитывая абсолютно динамический характер Python:
перепечатать (не прерывая отладки) любую строку и повторно ее выполнить
Я делал такое во встроенном отладчике. Именно динамический характер интерпретатора позволяет сделать вообще всё: пропустить строку, выполнить строку дважды, выполнить её 100 раз, изменить и выполнить - сколько угодно. Чуть больше надо постараться (видел отладчик с таким, не помню уже названия) модифицировать код на ходу, так, чтобы дальше выполнялся модифицированный. Всё это делается, никакого VBA не нужно.
отмотать выполняемую строку как угодно далеко назад/вперед и выполнить код
Вот тут не уверен, что вы имеете в виду. Если просто выполнить код из любой строки, то тоже можно. Если сделать откат состояния программы назад, то я такого не видел, но сомневаюсь, что и с VBA такое есть.
VBA хоронят с момента появления, но он упорно не мрет и живет в рейтингах.
Только для среды Windows, наверно. У меня 99+% всей работы в Unix, в основном в Linux, я его не вижу и про него не помню. Ну да, где-то на другой планете такое есть, только непонятно, зачем туда летать.
По этой вашей странной логике в топе должен быть и Ruby.
У Ruby роль {} реализована точно так же, "скобками", которые заканчиваются словом end. Оппонент недостаточно чётко выразился, я понимаю, что он имел в виду, хоть и не согласен.
что многое говорит об "любви" разработчиков к отступам.
Я добавлю, что отступы как средство группировки неудобны для поиска границ блоков (особенно если заканчивается несколько блоков) и для ручного рефакторинга в IDE или просто в редакторах. Не знаю, сколько ещё Python будет их держать (или вместо него не придёт другое аналогичное средство), но регулярно это задалбывает.
Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
CPU общего назначения на ней не изобрести
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.
Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ. А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
А LE как раз логичен - младшие разряды в байте с младшим адресом
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE. А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания. Не будет тут универсальности, не надейтесь.
Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
Именно что pytest анализирует код тестов (результат их парсинга питоновским парсером в виде AST), находит assertʼы и дорабатывает их. Это в отличие от unittest, который так отрабатывает только свои методы.
смотрим чем наиболее он существенно синтаксически отличается
Ну вот и следующий вопрос - а почему вы взяли именно эти синтаксические отличия, а не, например, динамическую типизацию, "batteries included" и предельное облегчение интерактивной работы? А отступы много где есть как синтаксический элемент...
Как-то забыл эту тему, случайно вспомнил... мы рядом чуть глубже обсуждали, но таки лучше вынести в отдельное сообщение:
Пофикшено в RFC 8260 чанками I-DATA.
Нет. Нету раздельного приёмного окна для каждого потока, значит, ты говоришь о чём-то другом, но не том, что я имею в виду. Возможность передавать огромные сообщения по кусочкам это, конечно, прикольно, но такой разрез с чуть большей затратой можно сделать и в юзерленде (добавить, например, один байт с теми же однобитовыми флагами B и E, или вообще впихнуть их в PPID).
Когда потоков много, общий ACK будет гораздо эффективнее
И он будет означать только то, что что-то услышано, но не что данные приняты - это если в пакете были чанки нескольких потоков, из которых из одного данные приняты, а другого - нет, потому что окна нету. Увы.
Для раутеров всё совсем не так, чем толще, тем больше специфика.
Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.
И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
Не.
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
Он менялся несколько раз в ключевых подсистемах.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
Нет, как раз раньше, причём даже 8008. https://stackoverflow.com/a/36263273/
Ага, мы-то знаем, что такое PDP endian :))
У PDP-11 сам LE заметно маскировался восьмеричными форматами для человека, и плотным упором на 16-битные значения. Что там слегка "под капотом" LE, тогда, конечно, знали, но прямого внимания не было, в отличие от x86, где уже на уровне машкодов побайтное представление давало, что LE просто бросалось в глаза, как сердитая кошка.
Обсуждаемый RISC-V как раз действует по принципу "всё, о чём у нас нет своего твёрдого мнения, делаем, как в x86". Это хорошо видно по, например, организации виртуальной памяти.
Это если они влезают в монитор. Вероятно, у вас 200% зрение. У меня оно "так себе", и я не могу поместить в один экран на постоянную, чтобы работать с ним, более, условно, 30 строк. Конечно, кто-то вспомнит "дядюшку Боба", но функции с блоками на 50-100-200 строк реально бывают, хоть и мало. И вот тут оказывается, что, особенно когда у тебя одновременно закрывается несколько блоков, найти, где они начались - уже квест.
А с языком, где {} (и тем более они обязательны - Go, Rust, много других современных; или C/C++ с форсированной политикой всегда делать блоки, как я всем рекомендую) - перейти к парной скобке это тривиально.
А ещё, когда ты вставляешь блок кода из другого места, IDE с Питоном очень часто ошибается в выборе нужного отступа. Имея же скобки {} или хотя бы then-end, else-end, do-end, etc., такой проблемы никогда не будет.
Поэтому я при прочих равных против выделения отступами и за обязательные скобки блоков кода (лучше символами {}, но и словами тоже пойдёт).
И снова - если вся функция влезла в экран. Причём со всеми вложенными, если там есть замыкания.
Ага, тогда вложенность переносится в создание иначе нахер никому не нужных функций с отдельными именами. Причём если в каком-нибудь C++ можно их помечать inline и компилятор тогда их усиленно встроит, в Python это приводит к замедлению "на ровном месте".
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
Да, я в курсе про YAML (не знаю, зачем вы вспомнили TOML). У него, по сути, те же проблемы -это если не считать того, что формат и в других аспектах чудовищно сложен и запутан - так что он скорее контрпример. JSON с некоторыми облегчениями типа финальной запятой и комментариями, и принудительным форматированием тут был бы полезнее.
Это крайне странное утверждение, учитывая абсолютно динамический характер Python:
Я делал такое во встроенном отладчике. Именно динамический характер интерпретатора позволяет сделать вообще всё: пропустить строку, выполнить строку дважды, выполнить её 100 раз, изменить и выполнить - сколько угодно. Чуть больше надо постараться (видел отладчик с таким, не помню уже названия) модифицировать код на ходу, так, чтобы дальше выполнялся модифицированный. Всё это делается, никакого VBA не нужно.
Вот тут не уверен, что вы имеете в виду. Если просто выполнить код из любой строки, то тоже можно. Если сделать откат состояния программы назад, то я такого не видел, но сомневаюсь, что и с VBA такое есть.
Только для среды Windows, наверно. У меня 99+% всей работы в Unix, в основном в Linux, я его не вижу и про него не помню. Ну да, где-то на другой планете такое есть, только непонятно, зачем туда летать.
Отличная сводка, спасибо:)
У Ruby роль {} реализована точно так же, "скобками", которые заканчиваются словом end. Оппонент недостаточно чётко выразился, я понимаю, что он имел в виду, хоть и не согласен.
Я добавлю, что отступы как средство группировки неудобны для поиска границ блоков (особенно если заканчивается несколько блоков) и для ручного рефакторинга в IDE или просто в редакторах. Не знаю, сколько ещё Python будет их держать (или вместо него не придёт другое аналогичное средство), но регулярно это задалбывает.
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.
Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ.
А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
И какая польза была бы в том, что мы "знали" бы вес разрядов?
Никаких "вешалок". Два индекса вместо одного, или смещение к одному из индексов. Чуть-чуть менее удобно, но подъёмно без проблем.
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE.
А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания.
Не будет тут универсальности, не надейтесь.
Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
Именно что pytest анализирует код тестов (результат их парсинга питоновским парсером в виде AST), находит assertʼы и дорабатывает их. Это в отличие от unittest, который так отрабатывает только свои методы.
Ну вот и следующий вопрос - а почему вы взяли именно эти синтаксические отличия, а не, например, динамическую типизацию, "batteries included" и предельное облегчение интерактивной работы?
А отступы много где есть как синтаксический элемент...
Этому есть подтверждение? (опрос/анализ UX от приличного агенства)
Как-то забыл эту тему, случайно вспомнил... мы рядом чуть глубже обсуждали, но таки лучше вынести в отдельное сообщение:
Нет. Нету раздельного приёмного окна для каждого потока, значит, ты говоришь о чём-то другом, но не том, что я имею в виду. Возможность передавать огромные сообщения по кусочкам это, конечно, прикольно, но такой разрез с чуть большей затратой можно сделать и в юзерленде (добавить, например, один байт с теми же однобитовыми флагами B и E, или вообще впихнуть их в PPID).
И он будет означать только то, что что-то услышано, но не что данные приняты - это если в пакете были чанки нескольких потоков, из которых из одного данные приняты, а другого - нет, потому что окна нету. Увы.