Возможно ли реализовать TCP на Delphi?

Question

[Mors Clamor]

Здравствуйте! В образовательных целях хочу реализовать какой-то совсем базовый функционал TCP самостоятельно на Delphi, поскольку это единственный Standalone язык который я хорошо знаю. В ходе изучения вопроса выяснил, что в винде RAW-sockets с последних версий не могут быть использованы для создания TCP сессий и ряда других функций. Так что мой взгляд упал на программы для создания пакетов на низком уровне типа npcap. У npcap есть заголовочые файлы только для C++, я перенес пару функций на Delphi, типа перечисления интерфейсов, НО у npcap (который в свою очередь использует под капотом libcap) вся работа строится на одной большой сложной структуре pcap_t, в которой много ссылок на всякие разные другие функции, короче это долго и сложно переносить.

Вопрос: как можно реализовать то, что я хочу? Либо уже изучить плюсы будет быстрее, либо откатить винду (воткнуть виртуалку?) на 7, где raw sockets еще были нормальными? Или есть какие-то более удобные, быстрые решения этого вопроса?

Comments

[Mors Clamor]

Я уточнил, что ограничения были уже на WinXP SP2, а откат так далеко может быть невозможен по ряду причин...

[res2001]

RAW-sockets с последних версий не могут быть использованы для создания TCP сессий

Зачем TCP сессии? Вы же делаете грубо говоря MyTCP, а про MyTCP сессии ограничений нет :-)
Вы не сделаете замену "родному" TCP, т.к. для этого нужно его убрать из системы и добавить свой. Как минимум у TCP фиксированный идентификатор протокола в IP заголовке и там не может быть 2 вариантов обрвботчика TCP.
Поэтому вы делаете свой протокол с поддержкой соединений + представление данных в виде потока.

который в свою очередь использует под капотом libcap

libcap - это не про сокеты. Видимо имелось ввиду libpcap.
Зачем pcap и прочее?
Делайте свой TCP на базе UDP.
Подход будет практически таким же, как если бы вы делали на сыром IP сокете.

[Mors Clamor]

res2001, я уже думал по поводу "своего" tcp, точнее, своей "виртуальной среды" для него. И, хотелось бы иметь всё же в качестве "собеседника" эталонный tcp-сервер (или клиент). А он должен уметь работать с моей "виртуальной средой", что невозможно. Точнее, я хотел бы проверять корректность работы такого себе TCP :) В любом случае, вы рекомендуете использовать именно UDP?

[res2001]

Mors Clamor,

В любом случае, вы рекомендуете использовать именно UDP?

UDP я рекомендую, если бы вы просто ограничились своим протоколом ориентированным на соединение с гарантией доставки и потоковой передачей данных без претензий на совместимость с TCP. Реализовать такой свой протокол никак не связанный с TCP гораздо проще, чем делать альтернативную реализацию совместимую с TCP.

Если же очень хочется совместимости с TCP, то UDP не подойдет точно.
Не уверен, что это можно сделать на винде, я просто не в теме.

В линуксе это возможно можно, и я видел альтернативные реализации стека TCP/IP работающие в линуксе параллельно родному стеку, но на отдельном сетевом адаптере. Я видел работающую систему на Линукс, где в качестве альтернативной реализации был стек TCP/IP выдернутый из OpenBSD и немного допиленный под потребности конкректного использования. Если что, сам я не принимал участия в этой разработке, знаю только теоретически ну и видел уже итоговый результат в работе.

Работает это примерно следующим образом:
1. Надо очистить стандартные настройки TCP/IP для выбранного сетевого адаптера
2. Средствами iptables и traffic control (tc) блокируется весь трафик на выбранном сетевом адаптере - это позволяет минимизировать расходы на стандартную обработку в ядре
3. В своей реализации для работы в user space на линуксе используются PF_PACKET сокеты (не PF_INET) - это сырые Ethernet сокеты, пакеты вы будете получать вместе с Ethernet заголовком и т.п. и тут уже вы вольны реализовыввать любые протоколы над Ethernet, в т.ч. и альтернативный стек TCP/IP. Но при этом IP то же надо будет реализовывать, а вместе с ним и ARP и ICMP. PF_SOCKETы работают еще до правил iptables и tc, поэтому заблокированный фаервол в п.2 не будет мешать вашему сокету. Вот тут на вики есть картинка со схемой прохождения пакетов и тут видно, что в PF_PACKET сокет пакеты уходят по отдельной ветке обработки (дублируются): https://en.wikipedia.org/wiki/Netfilter

Есть аналогичные разработки достаточно известные в узких кругах :) DPDK, PF_XDP (реализован в ядре линукса для обхода стандартного стека, особо не вникал), OpenFastPath - стек TCP/IP в user space.

Вероятно можно заменить только реализацию TCP, но не весь TCP/IP. Возможно тут помогут сокеты PF_INET/SOCK_RAW, но тут я ничего не скажу, т.к. не интересовался подобным сценарием.
Возможно подход будет примерно похожим с блокировкой средствами стандартного фаервола всех стандартных TCP пакетов и своей обработкой TCP пакетов. В таком случае вы получите функционал IP/ARP/ICMP/UDP из ядра, а TCP будет ваш собственный.

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

Обратите внимание, что все вышеизложенные проблемы не связаны с конкретной реализацией протокола ориентированного на соединение, а связаны со встраиванием вашей реализации в стандартную модель. Вы хотите разобраться с этим, ну тогда вперед. Но если задача понять как делать протокол, то не зачем ворошить вот эти все глубины. Вполне можно реализовать протокол подобный TCP на базе UDP. Но он не будет совместим с TCP даже если вы постараетесь его повторить полностью, и клиента надо будет делать своего. Но это меньшая проблема, чем те, с которыми вы столкнетесь, если будете замещать стандартную реализацию TCP.

[Mors Clamor]

res2001, ого) Ну я не настолько хардкорщик) Я понимаю, что поверх udp надо будет и клиента своего писать, это не проблема. Я хочу понять/реализовать как считаются контрольные суммы, формируются пакеты (теория это одно, а пощупать рукам эт другое), так вот если я что-то не так понял в самом алгоритме рассчета контрольных сумм, и реализую его неправильно и на клиенте и на сервере, то у меня, конечно, получится tcp-like протокол, но он будет фундаментально неправильным, хотя передача данных в нем, например, будет возможна.

А по поводу совместимости с ТРУ tcp - есть мысль сделать "адаптер" (Adapter.exe) с двумя сокетами - один тру tcp, другой "pseudo tcp over udp", с помощью этой прослойки декапсулировать трафик из udp со стороны моего приложения и, соответсвенно, инкапсулировать в udp со стороны true tcp клиента

[res2001]

Mors Clamor,

Я хочу понять/реализовать как считаются контрольные суммы

Не надо реализовывать контрольные суммы. Там используется какой-то вариант CRC. Используйте готовое решение. Кстати, в самом TCP, на сколько помню, используется CRC16, в Ethernet же используется CRC32, который конечно гораздо лучше справляется с задачей.
Если что, есть разные варианты CRC16 и СRС32, сам алгоритм один, но отличается например начальными значениями и т.п. Алгоритм CRC описан, если очень хочется в нем разобраться, можете почитать, но там больше математика, с программированием это не особо связано. На любителя в общем.

но он будет фундаментально неправильным,

Нет никакого фундаментально правильного или не правильного варианта. Ваша реализация может выполнять поставленные цели или не выполнять, вот и все. Если она не выполняет - значит вы где-то накосячили, надо разбираться. Если выполняет и скорость работы устраивает "заказчика" :-) значит все нормально. Для проверки выполняет или нет, надо конечно написать тесты, создать какие-то сложные условия "на линии" типа потеря пакетов, большие задержки, обрывы и т.п. Это все можно с эмитировать искусственно.

[Mors Clamor]

res2001, да, наверное, так и поступлю, спасибо) Оформите, пожалуйста, тоже как ответ

[res2001]

Mors Clamor, На счет контрольных сумм дополню.
Есть много всяких реализаций CRC, все они делают одно и то же. Самая быстрая - это табличная реализация, когда используется предварительно рассчитанный полином, записанный в константный массив. И потом над каждым байтом входного потока используя этот массив выполняются некоторые не сложные вычисления.
Такие реализации легко отличить - там основное место в коде занимает массив, а сами вычисления - это всего несколько строк кода.

[Mors Clamor]

res2001, ну упарываться в реализацию crc я всё же не буду) Начну с простого, если нужно будет - попробую реализовать преобразование tcp в псевдоtcp и наоборот, всё таки на прослушку у сокетов вроде как ограничений нет. А если есть, то WinDivert мне завести удалось на делфи

Answer 1

[res2001]

Написал ответ в комментариях тут.

Answer 2

[MVV]

В принципе, PCAP перенесли и в Windows (ключевое слово - WinPCAP), так что можно поэкспериментировать и в Windows.
В принципе, из Delphi можно вызывать функции API, написанные на C (С++ тут избыточен).
Вопрос только, как перенести описания функций в Delphi.
Почти наверняка это кто-то когда-то уже сделал, возможно - не единожды. Поищите по ключевым словам pcap и Delphi. Я, например, сразу наткнулся на ссылку https://github.com/den-kozlov/Snoop (но не спрашивайте меня, я туда даже не заглядывал).
PS Согласно старой (времен Win7/Win2K8R2) документации MS ограничения на работу raw socket с TCP были только на клиентских ОС, на серверные ОС они не распространялись (но надо было быть членом группы Админнистраторы). Может быть, это вам поможет.

А вообще, по жизни я согласен с предыдущим отвечающим Сергей Сахаров: не занимайтесь ерундой в образовательных целях.

Comments

[Mors Clamor]

Спасибо за ответ! Да, я видел этот репозиторий, но пока не ковырял досконально, смутило что вместо огромной структуры данных, которая фигурирует в качестве аргумента в любой функции на открытие адаптеров на чтение, там вот это
pcap_t = integer;
Может, оно как-то работает, хз. По поводу Windows Server - спасибо за наводку, поищу по поводу ограничений. Пока решил остановиться либо просто на псевдо tcp over udp между двумя своими приложениями, либо сделать третье приложение-адаптер для туннелирования pseudo tcp over tcp <-> true tcp

Answer 3

[VoidVolker]

Ставьте виртуалку в VirtualBox и не парьтесь с импортом сишных заголовков в дельфи.

Comments

[Mors Clamor]

почему этот вариант мне не слишком по душе - у меня не самый мощный пк, винда + рантайм всякий + Embarcadero RAD Studio могут сильно подорвать его здоровье. Но, наверное, это будет действительно самый удобный вариант. Слышал краем глаза, что в линухе с этим попроще, но под линух никогда не разрабатывал

[Mors Clamor]

Я уточнил, что ограничения были уже на WinXP SP2, а откат так далеко может быть невозможен по ряду причин...

[pfg21]

линукс если что вообще весь открыт :) можно под себя как угодно перекроить

Answer 4

[CityCat4]

как можно реализовать то, что я хочу?

Поставить линух и перестать пытаться сделать что-то неестественное в системе предназначенной для игрушки-кинушки-порнушки :)

Comments

[Mors Clamor]

я никогда не разрабатывал под линух от слова совсем. Более того, я и пользовался-то им хрен да нихрена... Но я рассмотрю этот вариант в любом случае, спасибо

[MVV]

Вы не правы. Windows - система не менее универсальная, чем Linux, и на ней тоже можно делать и нестандартные задачи. Только это будет ничем не проще, чем делать то де самое в Linux.
С Delphi и С - аналогично.
Только вот автору вопроса это мало поможет.

[CityCat4]

MVV,

система не менее универсальная

Аж два раза универсальная, ага.

Линух - вырос из многопользовательской (изначально, идеологически) системы для научных расчетов, работавшей на майнфреймах (гуглим историю UNIX)
Windows - выросла из однопользовательской MS-DOS, написанной для персонального (однопользовательского идеологически) компьютера. Развлекать юзера - было изначальной задачей DOS - ведь дна должна была привлекать покупателя!

[MVV]

CityCat4, давненько я не видел столько заблуждений в одном комментарии.

Линух - вырос из многопользовательской (изначально, идеологически) системы для научных расчетов, работавшей на майнфреймах (гуглим историю UNIX)

Linux никакого отношения к UNIX не имеет, кроме интерфейса (части набора системных вызовов, команд оболочки и т.п.). Ну, если на таком основании считать, что Linux - это UNIX, то тогда Windows (например Server 2008 R2 с установленным компонентом Services for Unix) - это тоже Unix, ровно на том же основании. Кода UNIX в Linux нет: это было установлено на судебном процессе "SCO против IBM". В реальности Linux ведет происхождение от аспирантской поделки одного финна (на самом деле, шведа), которая AFAIK развивала идеи чисто учебной системы Minix профессора Танненбаума, а в приличный вид - без Big Kernel Lock, без kerneld - загрузчика модулей ядра, работавшего в пользовательском пространстве и т.д., Linux привели инженеры IBM. Сейчас это мало кто помнит, но я вот - помню, с тем Linux (а именно - Slackware) мне пришлось поработать.
Что касается Unix, то он возник как ОС не для мейнфрейма (там свои ОС были), а для мини-ЭВМ. На мейнфреймы, его, конечно, переносили (я сам, ещё в СССР, видел такое чудо под названием "ДЕМОС" на виртуалке под VM/SP на ЕС 1045, и вроде как на голом железе оно тоже могло работать), но изначально он был сделан как ОС для компьютеров другого класса.
"Для научных рассчетов" - это воообще не показатель. Для этого некогда вообще без ОС обсходились :-) А лично я во времена оны использовал для этого и MS DOS(правда - запущенную как виртуалка в режиме V86 под DesqView, а на другой виртуалке я там, например, в Цивилизацию играл).
Современная Windows никакого отношения к MS DOS и старой Windows не имеет, кроме фирмы-производителя и части вызовов системных API. Современная Windows ведет свою историю от Windows NT, которая изначально разрабатывалась как система с вытесняющей многозадачностью, разделением доступа, и с подержкой многопользовательского режима через несколько Windows Station (хотя сейчас поддержка многопользовательского режима в Windows устроена немного по-другому). Идеоологически NT можно считать наследним ОС фирмы DEC (RSX-11, VAX VMS): основа команды разработки была оттуда и они принесли в проект NT много своих прежних идей: уровни прерываний, отложенные процедуры обраотки, полностью асинхронный ввод-вывод на уровне ядра (чего, кстати, в Linux нет и вряд ли будет - такие вещи надо заклдывать в изначальный проект)...
Развлекать пользователя не было изначальной задачей IBM PC (для которого и была изначально разработана DOS) - это видно, к примеру, по тому, что у него была очень слабая графика (CGA), уступающая графике типичного 8-битового компьютера. Но предназначением IBM PC было использование для деловых задач, и для этого такой графики хватало. Соответственно, покупателей (а это были не только и не столько частные лица) привлекал этот компьютер возможностями использования для бизнеса, а не для игр.

[CityCat4]

Linux никакого отношения к UNIX не имеет,

Дальше в принципе можно было и не читать ;) но у меня сейчас бэкап копируется, временно бездельничаю, так что давай побакланим, что ли, знаток истории, елы-палы :)

Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

Узнаваемые строки, не правда ли? Письмо написано в группу Usenet comp.os.minix, где общались между собой люди, использующие minix, UINIX-подобную ОС, написанную Эндрю Танненбаумом.
То, что Линус работал на компе с MINIX, почему он там оказался и что его сподвигло на создание собственной ОС - хорошо написано здесь. Прочитай, и сразу станет понятно, что Linux имеет самое прямое отношение к UNIX, несмотря на то, что в нем нет ни кода BSD ни кода minix

Windows (например Server 2008 R2 с установленным компонентом Services for Unix) - это тоже Unix

Угу, а линух с установленным wine - это винда, потому что я могу запускать виндовые бинарники. Или FreeBSD с установленным слоем совместимости с линухом - это линух, потому что он запускает линуховые бинарники, так получается да?

Кода UNIX в Linux нет:

Кода нет, а отношение есть. Если бы не minix, Линус не написал бы свою ось - minix был коряв и неудобен для его целей. Ось Танненбаума вдохновила его и он решил "сделаю-ка то же самое, но с блэкджеком и девочками..."

в приличный вид ... Linux привели инженеры IBM.

Это в 2001, после выхода IBM из "Проект Монтеррей"? А до этого значит, вид был неприличный? И все те люди, которые скачивали и дополняли линух все эти десять лет - они ничего приличного не сделали? ну-ну...

но я вот - помню, с тем Linux (а именно - Slackware) мне пришлось поработать.

С 8.1? С 9.0? или с "неприличными" версиями, еще не знавшими рук инженеров ibm? Я тогда вовсю гонял FreeBSD 4.4-RELEASE...

видел такое чудо под названием "ДЕМОС" на виртуалке под VM/SP на ЕС 1045

на EC-1046. на ЕС-1045 работала MFT/MVT/SVS и никакой виртуализацией там и не пахло (если конечно за оную не считать SYS1.PAGE)

А лично я во времена оны использовал для этого и MS DOS

MS-DOS 3.3? С максимальным размером диска 10М? Где диск размером "аж 20Мб" приходилось бить пополам? Ну... руководство завода, где я в то время работал, вполне разумно считало, что при наличии целых EC-1045 и EC-1046, заниматься какими-то игрушками сымсла не имеет. А вот в бухгалтерию завода были закуплены "аж 386" - мы на них ходили смотреть, как на диковинку... 1993 год...

я там, например, в Цивилизацию играл)

Вот именно. И я там играл. И в циву, и в F-117, и в Принца Персии и в Airborne Ranger и еще в чертову прорву разных игр - потому что ни для чего другого она не годилась - только играть и быть терминалом EC ЭВМ.

Современная Windows никакого отношения к MS DOS и старой Windows не имеет,

Ага, конечно. А поддержка win16, которую выпилили только из висты, конечно там так просто была. И даже в более современных, вплоть до десятки win16 запускалась в 32-битной версии.

Современная Windows ведет свою историю от Windows NT, которая изначально разрабатывалась как система с вытесняющей многозадачностью, разделением доступа,

Угу и именно поэтому при подключении по RDP к любой не-серверной винде тебя выкидывает из локальной сессии. Настоящее разделение доступа - попользовался - отойди! Линух (да и другой UNIX, тот же FreeBSD), на котором может одновременно работать десяток юзеров через удаленный Х-сервер (я не огворился, в Х сервер там, где клава и мышь) - смотрит на это с недоумением...

основа команды разработки была оттуда и они принесли в проект NT много своих прежних идей

Угу, принесли в буквальном смысле. Так что DEC судился с M$ обвиняя ее в краже интенллектуальной собственности. Ну и кроме того, NT - развитие проекта OS/2, который M$ вела совместно с IBM. "Ось" была хорошей осью, я на ней проработал почти два года, жаль что ее разработка была заброшена...

Но предназначением IBM PC было использование для деловых задач,

(а это были не только и не столько частные лица)

Угу и именно поэтому в IBM при выпуске IBM PC была развернута настоящая маркетинговая компания, использущая образ Чарли Чаплина (самое то для бизнеса, да?) и проходящая под девизом "компьютер в каждый дом"? (пруф)
(И уже тогда никому до этого неизвестная компания Micro-soft (тогда ее название писалось именно так) поставит туда MS-DOS 1.0)

Ох... многабукаф... но я люблю такие вопросы. Также как кошка постоянно точит свои когти об деревяшки, я постоянно "затачиваю" мозги об такие вопросы. Заодно и интересное кое-что узнаешь...

[Mors Clamor]

CityCat4, MVV, господа, несмотря на все ваши очень убедительные аргументы, и, безусловно, важную тему для дискуссии, предлагаю вам продолжить всё же в другом месте, например "битва публикаций на хабре", а тут мало того что не все смогут оценить ваши глубокие познания в данной теме, так еще и могут рассказать что такое нюанс

[CityCat4]

Mors Clamor, Согласен, а то сейчас придет лесник... На "большом" хабре кстати я принципиально ничего не публикую.

Answer 5

[Сергей Сахаров]

В образовательных целях лучше не заниматься ерундой и не изобретать велосипеды.

В крайнем случае если уж так припёрло - скачать FreeDOS или Linux - и посмотреть исходники.

А лучшее понимание стека TCP/IP даёт настройка файрволла - к примеру, pf

Comments

[Mors Clamor]

Никак не понял, как поможет настройка файрволла помочь в вопросе понимания TCP, но я и не занимался таким. Совсем совсем теорию о том, как оно работает я в курсе, мне интересны больше технические моменты, типа "как именно реализовано окно передачи, окно перегрузки", отслеживание пакетов на предмет доставки/недоставки. То есть именно "под капотом". Но не всё, на весь tcp у меня не хватит ни времени ни желания

[Сергей Сахаров]

Mors Clamor, написать-то можно, но ИМХО Delphi - не самый подходящий для этого инструмент. Лучше посмотреть в сторону FPC, а то и чистого C++

Настройка файрволла поможет помочь разобраться в типах пакетов и их маршрутизации (теория). Увы, практическая реализация - достаточно низкий уровень, многим недоступный.

Answer 6

[EDIsaev]

На Delphi можно написать всё! Даже сама среда Delphi написана на Delphi)
Но в данном случае разве что в чисто образовательных целях... т.к. нет иначе смысла изобретать колесо