OSDev

Ну да, я не совсем прав. Тем не менее, прямо TCP/IP OSI не соответствует.

Nable,
Ой, да знаю я эту структуру, не надо буквоедствовать. Просто перечислил человеку, напуганному страшным списком протоколов (куда под видом сетевых попали даже JPEG и MPEG), минимум, который ему необходимо реализовать. Конечно при реализации он, надеюсь, обложится документами RFC и вникнет в структуру более детально. Эта OSI модель сама по себе избыточно формальна и несколько оторвана от жизни. Кроме того, в любом случае все эти семь уровней так или иначе группируются в три кучи:
1. То, что предоставляет драйвер (1 уровень);
2. То, что представляет система (2-5);
3. То, о чём заботится приложение (6-7).
Я лишь отметил, что большинство протоколов лежит в группе 3, из которой реализовать надо совсем не много. Да и из 2-й тоже нужно далеко не всё.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я так понял, что то, что предоставляет драйвер это просто пакеты в буфере у сетевухи и нам полюбому надо от туда побайтово данные достать иначе там будут уже другие данные, т.к. она туда их покругу пишет. Сами заголовки нам не нужно от туда доставать, а только читать тип протокола, передать ссылку драйверу этого протокола, он там для себя посмотрит свой заголовок. А сами данные, например файл нужно из буфера доставать побайтово, что не есть очень хорошо, но видимо это из за того, что реализовать аппаратно все протоколы не реально.

Если тип пакета не определён то его вообще пропускаем, причём выдя в интернет пропускать придётся очень часто.

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

У rtl8139 есть 7бит WRAP запрещает разрывать пакет и если меньше чем 64K + 16 byte, то пакет будет выходить за буфер, зато будет цел всегда, и я буду включать этот бит полюбому. В сетевушке RTL8111B/RTL8168B вообще нету разрывов пакетов, там флаг последнего пакета в буфере, после чего просто возвращаешся в начало.
Чтобы успевать за буфером нужно, чтобы протоколы в пакете переваривались быстро и при нахождении куска файла в 512байт сразу винт его на сектор копировал. Дублировать буфер сетевухи точно нельзя, проц займёт и время отнимет.

Кстати драйвер от КоОС не включает этот бит, так что можно сказать о этой системе как о недоразумении. А разрыв пакета нормальные сетевухи уже не поддерживают.

> так что можно сказать о этой системе как о недоразумении
фи, как грубо. А почему бы не сказать о баге разработчикам, а лучше самому пофиксить и патч послать?

Система, конечно, сплошное недоразумение, но уж точно не по этой причине.

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

А если протокол нашёл кусок файла в 512мб, то отдав его диску на запись в сектор он не сможет записать его из разных мест.
Может быть всётаки они его там уже и включают, я не уверен, просто думал, что хоть на это сообщение ктото отреагирует не весело тут както

У сетевушки RTL8111B_8168B буфер состоит из списка пакетов в которых адреса на место куда писать пакеты, я сделал список из 256 и байтовый указатель на текущий пакет сам при добавлении последнего пакета возвращается на первый, так, что проверки делать не нужно. Настрою для начала протокол АРП на получение широковещательных пактов и добавление адресов в список адресов.
При заполнении пакета сетевуха поставит бит в 0 и если он нам нужен на долго мы просто подменим адрес и не нжно копировать его, крутая система. Уже создал и сформировал буфер и его блоки плюс резервные, rtl8139 вообще не буду поддерживать, только современные с такой системой.
Причём моя сетевуха также ставит бит если определяет стандартные 3 протокола.