Board.KolibriOS.org

most likely a bug in TCP code.
I have no means to further fix the current stack, but am working on a complete rewrite instead. (kernel/branches/net/)

Perhaps you can convert the 3com driver to work on the new stack, if you are interessed.
more info: http://wiki.kolibrios.org/New_stack

Если исправить в файле socket.inc строчку на то разрыв соединения (с программой, работающей под WinXP) происходит нормально.
Даже ftps вроде заработал (хотя через некоторое время всё же глюкнул и больше не реагировал на попытки соединения).

А если ещё исправить ftps, чтобы локальный порт для dataconnection выбирался системой (и укоротить задержку при закрытии соединения до 100мс), то им даже можно пользоваться.

Посмотрел на происходящее в Wireshark, в исходном варианте он ругается "Broken TCP. The acknowledge field is nonzero while the ACK flag is not set". RFC по TCP не читал, но Wireshark'у верю, и фикс вполне логичен. Залил на svn.

Как я уже давно писал, думаю, что самая реальная и близкая возможность увеличить число пользователей колибри - это увеличение числа поддерживаемых сетевых карт и других способов подключения к интернет, а так же поддержка (создание) современного браузера. Я имею ввиду, что путь, по которому сейчас пошла Chrome OS для колибри наиболее близок.

Что вы думаете уважаемые разработчики?

Denis F.
Действуй. Думаю, против результатов возражать никто не будет.

Я не программист. Мне просто очень интересно ваше мнение? На сколько это реально? Как вы относитесь к такому пути развития?

Я имею ввиду, что путь, по которому сейчас пошла Chrome OS для колибри наиболее близок.

Что вы думаете уважаемые разработчики?

Моё мнение. Не реально, не нужно, глупо.

Denis F. wrote:Я не программист. Мне просто очень интересно ваше мнение? На сколько это реально? Как вы относитесь к такому пути развития?

Тогда это не сюда, а в тему viewtopic.php?f=8&t=677, а здесь это явный оффтоп.

diamond wrote:Посмотрел на происходящее в Wireshark, в исходном варианте он ругается "Broken TCP. The acknowledge field is nonzero while the ACK flag is not set". RFC по TCP не читал, но Wireshark'у верю, и фикс вполне логичен.

А я чего-то засомневался. Приведённое сообщение говорит лишь о том, что если мы не ставим ACK flag, то поле acknowledge нужно оставить нулевым, а мы его всегда заполняем. Надо бы проверить, будет ли соединение нормально закрываться если мы откатим изменение socket.inc, но изменим build_tcp_packet в tcp.inc так, чтобы если нет флага ACK, то поле acknowledge делать нулевым.

P.S. Не, всё правильно. Вычитал в интернете, что FIN всегда посылается вместе с ACK.

Я закоммитил пару изменений на SVN. По крайней мере, теперь ftps не виснет. Проверял в QEMU и на реальном компьютере с сетевой картой 3com.

diamond

Может лучше выравнивать секции в coff.dll на 4 Кб ?

Просмотрел последние ревизии ядра.
Если я правильно понял, то в ревизиях 1289,1292 реализован метод работы с DLL через расшаренную память. То есть загруженная DLL используется совместно несколькими программами. Я правильно понял или нет?
Вникать в реализацию не стал. Экономлю время .

Serge
Полагаю, это зависит от конкретной ситуации. В svn.1296 сделал выбор выравнивания по соответствующему полю из заголовка секции, чтобы его можно было подгонять при желании. Умолчальное значение поставил в 4096.
andrew_programmer
В общих чертах - да, физическая память под неизменёнными страницами из всех экземпляров одной библиотеки одна и та же.

В последней ночной сборке падает screenshooter при попытке сделать скриншот.