Как два байта переслать
Жарг. комп., мол. Легко, без труда. Рус. радио, 1998. /em> Трансформация выражения как два пальца обоссать.
Большой словарь русских поговорок. — М: Олма Медиа Групп . В. М. Мокиенко, Т. Г. Никитина . 2007 .
- На русский байрам
- Взорвать бак
Смотреть что такое «Как два байта переслать» в других словарях:
- Легко, как два пальца обоссать — О простоте, лёгкости выполнения какого то дела. Среди компьютерщиков распространён созвучный вариант: Как два байта переслать … Словарь народной фразеологии
- как пить дать — См … Словарь синонимов
- БАЙТ — Как два байта переслать. Жарг. комп., мол. Легко, без труда. Рус. радио, 1998. /em> Трансформация выражения как два пальца обоссать … Большой словарь русских поговорок
- Кулхацкер — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- АПВС — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- ЕВПОЧЯ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- ЕМНИП — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- ЗОМГ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- ЗЫ — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
- Зомг — Компьютерный сленг разновидность сленга, используемого как профессиональной группой IT специалистов, так и другими пользователями компьютеров. История Появление терминов Бурный рост со второй половины XX века компьютерных технологий, и, в… … Википедия
есть такое выражение:»Как 2 байта переслать!»
Представляешь, что должно произойти, чтобы возникнуло выражение: «Как 2 ГИГАбайта передать по инету».
Похожие вопросы
Ваш браузер устарел
Мы постоянно добавляем новый функционал в основной интерфейс проекта. К сожалению, старые браузеры не в состоянии качественно работать с современными программными продуктами. Для корректной работы используйте последние версии браузеров Chrome, Mozilla Firefox, Opera, Microsoft Edge или установите браузер Atom.
Как два байта переслать: контрибьютим в KPHP
KPHP — компилятор для PHP. Он конвертирует PHP код в код на C++, компилируя который, ускоряет производительность в десятки раз. Это open-source проект, созданный ВКонтакте. Благодаря ему собирается огромный монолит ВКонтакте на 9 миллионов строк PHP кода в обычный бинарник, запуская который вы локально поднимаете полноценный ВКонтакте.
Цель
Я расскажу про добавление новых функций в runtime KPHP. Точнее про тернистую дорогу на пути.
План
- Подготовка
- runtime
- добавление функций
- типы
- флаги
- изменение подключаемых библиотек
- Тесты
- cpp тесты
- php тесты
- pull_request
Подготовка
runtime
Добавление функций
В качестве примера возьмем ситуацию, когда нам нужно реализовать функцию mb_check_encoding из php. Первым делом идем в доки:
Узнаем, что функция проверяет кодировку строки или массива строк. Массив строк обрабатывается рекурсивно, так что сфокусируемся на функции, работающей для строки. Теперь идем в код php смотреть как работает функция в php:
Идем смотреть в сишный файл, чтобы протрейсить реализацию:
Видим, что конвертация идет через входной параметр типа mbfl_encoding . Ищем:
Сразу видим, что эта структура — часть какой-то библиотеки libmbfl , которая видимо и занимается конвертацией. Ищем ее в интернете и находим репозиторий:
Отлично, мы поняли, что нам нужно лишь использовать эту библиотеку, которая возьмет всю конвертацию на себя, а мы просто допишем интерфейс. Скачиваем эту библиотеку, устанавливаем, изучаем ее и пишем реализацию в любом сишном файлике (не внутри kphp, сейчас нам надо, чтобы просто работало). Для проверки кодировки нужна функция конвертации mb_convert_encoding , которую мы тоже реализуем:
#include mbfl_string *mb_convert_encoding(const char *str, const char *to, const char *from) < int len = strlen(str); enum mbfl_no_encoding from_encoding, to_encoding; mbfl_buffer_converter *convd = NULL; mbfl_string _string, result, *ret; /* from internal to mbfl */ from_encoding = mbfl_name2no_encoding(from); to_encoding = mbfl_name2no_encoding(to); /* init buffer mbfl strings */ mbfl_string_init(&_string); mbfl_string_init(&result); _string.no_encoding = from_encoding; _string.len = len; _string.val = (unsigned char*)str; /* converting */ convd = mbfl_buffer_converter_new(from_encoding, to_encoding, 0); ret = mbfl_buffer_converter_feed_result(convd, &_string, &result); mbfl_buffer_converter_delete(convd); /* fix converting with multibyte encodings */ if (len % 2 != 0 && ret->len % 2 == 0 && len < ret->len) < ret->len++; ret->val[ret->len-1] = 63; > return ret; > bool mb_check_encoding(const char *value, const char *encoding) < /* init buffer mbfl strins */ mbfl_string _string; mbfl_string_init(&_string); _string.val = (unsigned char*)value; _string.len = strlen((char*)value); /* from internal to mbfl */ const mbfl_encoding *enc = mbfl_name2encoding(encoding); /* get all supported encodings */ const mbfl_encoding **encs = mbfl_get_supported_encodings(); int len = sizeof(**encs); /* identify encoding of input string */ /* Warning! String can be represented in different encodings, so check needed */ const mbfl_encoding *i_enc = mbfl_identify_encoding2(&_string, encs, len, 1); /* perform convering */ const char *i_enc_str = (const char*)mb_convert_encoding(value, i_enc->name, enc->name)->val; const char *enc_str = (const char*)mb_convert_encoding(i_enc_str, enc->name, i_enc->name)->val; /* check equality */ /* Warning! strcmp not working, because of different encodings */ bool res = true; for (int i = 0; i < strlen(enc_str); i++) if (enc_str[i] != value[i]) < res = false; break; >free((void*)i_enc_str); free((void*)enc_str); return res; > Функции работают, но только для сишных строк, теперь нам нужно перенести эти локально работающие функции в runtime kphp. Для этого есть 4 шага:
- Добавить php-интерфейс (txt)
- Добавить код с интерфейсом (h)
- Добавить код с реализацией (cpp)
- Добавить файлы в сборку (cmake)
Добавить php-интерфейс (txt)
Для того, чтобы правильно перенести php интерфейс, нужно знать про типы в kphp тут
Итак, открываем файл builtin-functions/_functions.txt . И в самый конец добавляем переделанный интерфейс из php. Например в php mb_check_encoding имеет следующий интерфейс:
function mb_check_encoding(array|string|null $value = null, ?string $encoding = null): boolв kphp это будет:
function mb_check_encoding(array|string|null $value = null, ?string $encoding = null): bool;Аналогично для mb_convert_encoding в php:
function mb_convert_encoding(array|string $string, string $to_encoding, array|string|null $from_encoding = null): array|string|falsefunction mb_convert_encoding(array|string $string, string $to_encoding, array|string|null $from_encoding = null): array|string|false;Вот и все, теперь нужно добавить код.
Добавить код с интерфейсом (h)
Все модули рантайма находятся в папке runtime . Наши функции являются частью расширения mbstring для php. Оказывается уже есть файлик mbstring.h . Давайте откроем и посмотрим:
Оказывается mb_check_encoding уже реализована, странно. Почему имя функций начинается на f$ ? Так kphp понимате какие функции искать в builtin-functions/_functions.txt . Посмотрим cpp файл:
Хм, функция уже реализована, но все работает только для двух кодировок (UTF-8 и Windows-1251). Ничего страшного, теперь мы покажем им все кодировки! (о последствиях расскажу в конце). Видим, что входными параметрами являются переменные типа string . Ловушка! Это не string из I/O! Это string из kphp! Где про нее почитать? Все типы включаются из runtime/kphp_core.h . Смотрим внутри: . Поменяем интерфейс mb_check_encoding :
bool f$mb_check_encoding(const string &value, const string &encoding);аналогично для mb_convert_encoding :
string f$mb_convert_encoding(const string &str, const string &to_encoding, const string &from_encoding);Отлично, идем дальше.
Добавить код с реализацией (cpp)
В предыдущем шаге мы нашли все типы, так что можно посмотреть в string.inl и узнать, как доставать из нее const char * , который нам уже знаком или как создать string из const char * . Теперь перепишем функцию mb_check_encoding :
bool f$mb_check_encoding(const string &value, const string &encoding) < const char *c_encoding = encoding.c_str(); const char *c_value = value.c_str(); // . >Теперь осталось сделать аналогичное для функции mb_convert_encoding :
string f$mb_convert_encoding(const string &str, const string &to_encoding, const string &from_encoding) < const char *c_string = s.c_str(); const char *c_to_encoding = to_encoding.c_str(); const char *c_from_encoding = from_encoding.c_str(); // . return string((const char*)ret->val, ret->len); >Добавить файлы в сборку (cmake)
Идем в runtime/runtime.cmake . Все cpp должны оказаться в KPHP_RUNTIME_SOURCES . Но для удобства можно группировать их. В нашем случае mbstring.cpp уже включен в сборку. Но, можно сделать по другому:
prepend(KPHP_RUNTIME_MBSTRING_SOURCES mbstring.cpp)тогда можно в KPHP_RUNTIME_SOURCES включать не отдельный файл mbstring.cpp , а KPHP_RUNTIME_MBSTRING_SOURCES :
prepend(KPHP_RUNTIME_SOURCES $/runtime/ $ . Фух, теперь точно все. Билдим!
mkdir build && cd build && cmake .. -DDOWNNLOAD_MISSING_LIBRARIES=On && make -j$(nproc)echo mb_check_encoding("Hello World", "UTF-8");./objs/bin/kphp2cpp -M test.php && ./kphp_out/cliУра! Мы успешно добавили новые функции в рантайм kphp!
. Важно .
Не все так просто. Мы очень быстро их добавили (лишь бы работало). Теперь когда мы убедились, что все работает нужно переделать некоторые моменты.
- И было бы хорошим тоном разграничивать логичное поведение функции и ее поведение в php. Например в php mb_convert_encoding если при конвертации есть символы, которых нет в выходной кодировке, то их байты заменяются на 0x63 (‘?’ в ASCII). Это поведение уникально, поэтому лучше ее реализовать в f$ функции, а всю логику вынести в обычную функцию.
- Нужны другие типы — mb_check_enсoding в качестве параметра данных может принимать массив строк или null , нужно это предусмотреть. Причем поведение функции должно быть идентично php (даже если поведение в php нелогично). Аналогично для mb_convert_encoding , которая может и принимать и возвращать строку или массив строк.
- mbstring это расширение kphp, которое в php-src , собирается и подключается только если указан определенный флаг при компиляции. Нужно сделать и это.
- Обработка разных версий php.
Хороший тон
- Используйте const & для входных параметров (если они не меняются)
- Разграничение логики и поведения как в php (используйте static ):
static bool check_enсoding(const char *value, const char *encoding) < // . >bool f$mb_check_encoding(const string &value, const string &encoding) < const char *c_encoding = encoding.c_str(); const char *c_value = value.c_str(); bool res = check_enсoding(c_value, c_encoding); // process differences in php return res >- Используйте noexcept если функция не вызывает исключений:
static bool check_enсoding(const char *value, const char *encoding) < // . >bool f$mb_check_encoding(const string &value, const string &encoding) noexcept < const char *c_encoding = encoding.c_str(); const char *c_value = value.c_str(); bool res = check_enсoding(c_value, c_encoding); // process differences in php return res >Типы
mb_check_encoding в качестве переменной данных может принимать string|array|null (судя по php-интерфейсу). В C++ мы не можем записывать типы так, поэтому заменяем тип на mixed (смешанный). Про mixed можно почитать аналогично типу string . Параметр кодировки mb_check_encoding (судя по php-интерфейсу) имеет тип ?string , что нужно заменить на Optional . Про Optional можно почитать аналогично типу string . Главная информация в том, что mixed мы можем проверять на любой тип через .is_ и попытаться привести к любому типу через .to_ . Из Optional можно достать значение через .val() .
static bool check_enсoding(const char *value, const char *encoding) < // . >bool f$mb_check_encoding(const mixed &value, const Optional &encoding) noexcept < if (encoding.is_null() || value.is_null()) return 1; const char *c_encoding = encoding.val().c_str(); if (value.is_string()) < // . >if (value.is_array()) < // . >return 1; >Расширение
mbstring это расширение php, его нужно включить через флаг при сборке с cmake . Пусть флагом будет — MBFL Чтобы это сделать нужно всего 3 шага:
- cmake/external-libraries.cmake — добавить флаг в cmake и пробросить его в компилятор:
option(DOWNLOAD_MISSING_LIBRARIES "download and build missing libraries if needed" OFF) option(MBFL "build mbstring" OFF) # . - runtime/runtime.cmake — включить файлы в сборку по флагу
# . if (MBFL) prepend(KPHP_RUNTIME_MBSTRING_SOURCES mbstring.cpp) endif() # . prepend(KPHP_RUNTIME_SOURCES $/runtime/ $ # . В моем случае некоторые функции из mbstring.cpp использовались в самом kphp (не в рантайме). Это значит, что мне нужно всегда собирать mbstring.cpp , но не собирать большинство функции по флагу. Чтобы это сделать нужно 3 шага:
- cmake/external-libraries.cmake — добавить флаг в cmake и пробросить его в компилятор:
option(DOWNLOAD_MISSING_LIBRARIES "download and build missing libraries if needed" OFF) option(MBFL "build mbstring" OFF) # . - compiler/compiler-settings.cpp — пробросить флаг дальше из компилятора в рантайм:
void CompilerSettings::init() < // . std::stringstream ss; #ifdef MBFL ss - runtime/mbstring.* - через #ifdef отслеживать флаг из cmake:
#ifdef MBFL bool f$mb_check_encoding(const mixed &value, const Optional &encoding) noexcept; #endif Теперь при сборке можно указать:
cmake .. -DMBFL=OnОбработка разных версий php
Изменение подключаемых библиотек
Все работает. Библиотека линкуется. Но было бы хорошо, если не нужно было бы ее устанавливать самому, чтобы kphp по флагу MBFL скачивал библиотеку, собирал и линковал. Тогда не придется писать новые доки для установки библиотеки + можно заморозить версию библиотеки на форке. Разберем мой форк libmbfl . Мне не повезло с библиотекой, она с 1992 года не обновляется, нет документации, нет статей с ее использование, нет комментариев к коду и билдится она по-своему. Чтобы kphp сам скачивал, билдил и линковал библиотеку нужно выполнить шагов:
- Убрать сборку 'по-своему'
- Создать таргеты, которые ищет kphp
- Включить сборку и линковку в cmake
- Добавить библиотеку в импорт компилятора
Убрать сборку 'по-своему'
Если в сборке библиотеку есть всякие ./configure , ./buildconf и прочее - переносим это в cmake . Нам нужно, чтобы библиотека собиралась только через cmake + make . В моем случае был и ./configure и ./buildconf , которые отвечали проверку зависимостей и сборку (каждый файл не собирался в своей папке, его собирали рядом с зависимостями). Я вручную починил все зависимости, чтобы каждый файл могу собираться по своему пути и добавил проверку зависимостей в cmake.
Создать таргеты, который ищет kphp
Когда kphp будет билдить библиотеку он будет ожидать специальные таргеты, чтобы знать какой код скопировать в include и где находится собранная библиотека.
Название библиотеки libmbfl , тогда kphp будет ожидать следующие таргеты:
- libmbfl
- libmbfl_ALL_SOURCES
- libmbfl-includecopy
Разберем по отдельности каждый, начнем с libmbfl .
libmbfl
project(libmbfl VERSION 1.0.0 DESCRIPTION "libmbfl" HOMEPAGE_URL "https://github.com/andreylzmw/libmbfl") # . set_target_properties(libmbfl PROPERTIES ARCHIVE_OUTPUT_DIRECTORY $) # . set_target_properties(libmbfl PROPERTIES PUBLIC_HEADER "libmbfl/mbfilter.h") # . add_dependencies(libmbfl libmbfl-includecopy) # . install(TARGETS libmbfl COMPONENT KPHP LIBRARY DESTINATION "$/$" ARCHIVE DESTINATION "$/$" PUBLIC_HEADER DESTINATION "$/$/kphp/liblibmbfl") # . add_library(libmbfl STATIC $) add_library(vk::libmbfl ALIAS libmbfl)libmbfl_ALL_SOURCES
set(libmbfl_ALL_SOURCES filters/mbfilter_iso2022_jp_ms.c filters/mbfilter_iso8859_14.c filters/mbfilter_iso8859_6.c filters/mbfilter_sjis_mobile.c filters/mbfilter_koi8r.c filters/mbfilter_cp850.c filters/mbfilter_euc_jp.c # . add_library(libmbfl STATIC $) # . libmbfl-includecopy
add_dependencies(libmbfl libmbfl-includecopy) # . add_custom_command( COMMAND cp -R $/mbfl $/include/kphp/libmbfl OUTPUT $/include/kphp/libmbfl/mbfl) add_custom_command( COMMAND cp -R $/filters $/include/kphp/libmbfl OUTPUT $/include/kphp/libmbfl/filters) add_custom_command( COMMAND cp -R $/nls $/include/kphp/libmbfl OUTPUT $/include/kphp/libmbfl/nls) # . add_custom_target(libmbfl-includecopy ALL DEPENDS include/kphp/libmbfl/mbfl/mbfilter.h) # . Включить сборку и линковку в cmake. cmake/external-libraries.cmake:
# . FetchContent_Declare(libmbfl GIT_REPOSITORY https://github.com/andreylzmw/libmbfl) FetchContent_MakeAvailable(libmbfl) include_directories($/include) add_definitions(-DLIBMBFL_LIB_DIR="$/objs") add_link_options(-L$/objs) # . Добавить библиотеку в импорт компилятора
Чтобы kphp мог линковать нужную нам библиотеку libmbfl нужно добавить ее (без lib в начале) в external_static_libs в compiler/compiler-settings.cpp :
std::vector external_static_libs;Тесты
cpp тесты
cpp тесты это тесты реализации, запускаются через сtest. В них мы заранее должны знать что должна вернуть функция и просто проверять. Добавить их просто. Для каждой функции отдельный тест. cpp тесты находятся в tests/cpp/runtime/ . Чтобы их добавить создаем mbstring-test.cpp внутри tests/cpp/runtime/ :
#include #include "runtime/mbstring/mbstring.h" // Note: all tests written for php8.3 /* TEST ASCII DATA */ const string &ASCII_STRING = string("sdf234"); const array &ASCII_ARRAY = array::create(string("234"), string("wef")); const string &ASCII_ENCODING = string("ASCII"); /* TEST WINDOWS1251 DATA */ const string &WINDOWS1251_STRING = string("sdfw3234ыва"); const array &WINDOWS1251_ARRAY = array::create(string("234"), string("wef"), string("ыва")); const string &WINDOWS1251_ENCODING = string("Windows-1251"); /* TEST UTF8 DATA */ const string &UTF8_STRING = string("Өd5па"); const array &UTF8_ARRAY = array::create(string("sdыа"), string("wef"), string("ыва"), string("Ө"), string("Ä°nanç Esasları")); const string &UTF8_ENCODING = string("UTF-8"); #ifdef MBFL TEST(mbstring_test, test_mb_check_encoding) < /* TEST ASCII ENCODING */ ASSERT_TRUE(f$mb_check_encoding(ASCII_STRING, ASCII_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(ASCII_ARRAY, ASCII_ENCODING)); ASSERT_FALSE(f$mb_check_encoding(WINDOWS1251_STRING, ASCII_ENCODING)); ASSERT_FALSE(f$mb_check_encoding(WINDOWS1251_ARRAY, ASCII_ENCODING)); ASSERT_FALSE(f$mb_check_encoding(UTF8_STRING, ASCII_ENCODING)); ASSERT_FALSE(f$mb_check_encoding(UTF8_ARRAY, ASCII_ENCODING)); /* TEST WINDOWS1251 ENCODING */ ASSERT_TRUE(f$mb_check_encoding(WINDOWS1251_STRING, WINDOWS1251_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(WINDOWS1251_ARRAY, WINDOWS1251_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(ASCII_STRING, WINDOWS1251_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(ASCII_ARRAY, WINDOWS1251_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(UTF8_STRING, WINDOWS1251_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(UTF8_ARRAY, WINDOWS1251_ENCODING)); /* TEST UTF8 ENCODING */ ASSERT_TRUE(f$mb_check_encoding(UTF8_STRING, UTF8_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(UTF8_ARRAY, UTF8_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(ASCII_STRING, UTF8_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(ASCII_ARRAY, UTF8_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(WINDOWS1251_STRING, UTF8_ENCODING)); ASSERT_TRUE(f$mb_check_encoding(WINDOWS1251_ARRAY, UTF8_ENCODING)); >TEST(mbstring_test, test_mb_convert_encoding) < /* input is string, encoding is string */ ASSERT_STREQ(f$mb_convert_encoding(ASCII_STRING, WINDOWS1251_ENCODING, ASCII_ENCODING).to_string().c_str(), ASCII_STRING.c_str()); ASSERT_STREQ(f$mb_convert_encoding(UTF8_STRING, UTF8_ENCODING, UTF8_ENCODING).to_string().c_str(), UTF8_STRING.c_str()); /* input is string, encoding is array of strings */ ASSERT_STREQ(f$mb_convert_encoding(ASCII_STRING, , ASCII_ENCODING).to_string().c_str(), ); > #endifСборка тестов находится в tests/cpp/runtime/runtime-tests.cmake , нужно добавить cpp файл в RUNTIME_TESTS_SOURCES :
prepend(RUNTIME_TESTS_SOURCES $/tests/cpp/runtime/ # . mbstring-test.cpp # . Теперь когда мы запустим ctest:
cd build && ctest -j$(nproc). 242/261 Test #242: mbstring_test.test_mb_check_encoding . Passed 0.24 sec 243/261 Test #243: mbstring_test.test_mb_convert_encoding . Passed 0.23 sec . php тесты
php тесты это тесты, которые сравнивают результат работы php и kphp, запускаются через tests/kphp_tester.py . В них мы пишем php код который должен вести себя ожидаемого в kphp. php тесты находятся в tests/phpt/ . Чтобы их добавить создаем папку mbstring внутри tests/phpt/ . Внутри создаем отдельный файл для каждой функции в формате 001_*****.php , 002_*****.php и тд, где ***** - названия функций. В нашем случае:
tests/phpt/mbstring/001_mb_convert_encoding.php :
@ok # If mbstring.language is "Japanese", "auto" is expanded to "ASCII,JIS,UTF-8,EUC-JP,SJIS" function test_mb_convert_encoding_auto() < $str = "Somebody was told: F$#$)UT#*HD]"; var_dump(mb_convert_encoding($str, "EUC-JP", "auto")); >mb_convert_encoding_not_utf_8(); test_mb_convert_encoding_auto();@ok function mb_check_encoding_not_utf_8() < $str = "The leading horse is white, the second horse is red, the third one is black, the last one is green"; var_dump(mb_check_encoding($str, "base64")); >mb_check_encoding_utf_8(); mb_check_encoding_not_utf_8();На первой строчке мы указываем ожидаемое поведение kphp для этого теста, например:
- @ok , если kphp должен успешно скомпилировать этот код
- @kphp_should_fail , если kphp не должен скомпилировать этот код и это ожидаемо
- @kphp_should_warn , если kphp не должен скомпилировать этот код и это ожидаемо + должен вывести ворнинг
Запустим тесты:
./kphp_tester.py phpt/mbstring/001_mb_convert_encoding.php :
pull_request
Мы добавили новые функции, учли все варианты поведения, добавили тесты. Теперь нужно грамотно оформить pull_request. Не поверите, но есть одно-единственное правило, на котором я погорел. Ломать не строить - нужно понимать, что целевым проектом для kphp является vk. vk это монолит из более 9 миллионов строк кода на php. Если вы заменяете какие-то функции своими, которые работают правильно (как я заменил все функции mbstring своими), то разработчикам vk нужно будет переписывать места использования этих функций, что им не нужно, так как vk работает и без ваших обновленных функций, поэтому лучшим вариантом является добавление новых (уже существующих) функций по флагам. Таким образом выигрывают все. Разработки vk не переписывают код и другие пользователи kphp могут получить ваш функционал для своих проектов.
Что касается остального правил особо нет - пишите, что вы добавили. Можете сделать ревью проще, прикрепив ссылки на документацию, откуда вы взяли функцию, которую реализовали. Если есть какие-то нюансы (по типу того, что вы используете свою модифицированную библиотеку), тоже просто пишите об этом.
Как два байта переслать?
Что может быть проще пересылки текстового сообщения «Hello!» с одного компьютера на другой? Да ничего сложного! Сейчас всё придумаем, а заодно заново изобретём велосипед.
Физический уровень
Для передачи воспользуемся обычным куском медной проволоки. Закодируем послание в двоичный код и будем подавать напряжение, когда надо будет передать единицу, и отключать, когда передаём ноль. На приёмнике сигнала, соответственно, будем расшифровывать сигнал по такому же принципу.
Предварительно договоримся, что каждому символу мы сопоставим определённое число, а затем передавать представление этого числа в двоичной форме.
На выходе из приёмника у нас получится вот такой вот график напряжения:
Теперь осталось просто взять и расшифровать этот сигнал на приёмнике. Включив передачу, мы обнаружили, что реальный мир быстро разрушил наши теоретические построения. Приёмник получил вовсе не то, что мы ожидали:
Оказалось, что на приёмное устройство включилось несколько позднее передающего, а кроме того, генераторы тактовой частоты у приёмника и передатчика несколько различаются. Хоть на них и написано 100 МГц, выяснилось, что приёмник работает с частотой 101,3 МГц, а передатчик – с частотой 100,9 МГц.
Разумеется, можно было бы оснастить два устройства высокоточными атомными часами, или использовать для синхронизации сигналы GPS (см. Маршрут построен), но это сильно дороже, чем мы рассчитывали. Вот, если бы нам удалось передать приёмнику тактовый сигнал передатчика. Подумав немного, мы решили добиться этого, закодировав сигнал, разделив каждый такт на 2 части. Ноль мы кодируем падением потенциала, а единицу – ростом:
Ура, нам удалось передать короткий текст с одного компьютера на другой! (А заодно мы заново изобрели Манчестерское кодирование, которое применяется в настоящее время в технологии Ethernet. Если вы зачистите пару проводов в сетевом кабеле и подключите их к осциллографу, вы увидите на экране картинку, очень похожую на эту:
Существуют и другие виды физического кодирования сигнала, но, чтобы описать их все, мне не хватит ни времени, ни места в посте).
Кстати об Ethernet-кабеле (Витой паре) – хотя внутри него находятся 8 проводов, для передачи сигнала со скоростью до 100 Мбит /с достаточно всего четырёх из них. Все восемь требуются лишь для передачи со скоростью свыше 1 Гбит/с.
Канальный уровень
Мы построили физический канал связи, но все наши проблемы пока не решены. Пока мы передавали короткие наборы данных, всё было прекрасно. Но на длинных пакетах данных очень часто возникала проблема «сдвига фазы». Приёмник просто не знает, где кончается одно сообщение, и начинается другое:
Нам нужен какой-то способ разделять разные блоки данных между собой, назовём их кадры (или фрейм, frame) чтобы приёмник мог точно знать, где заканчивается один пакет, и начинается другой. Поскольку всё, что мы можем передавать – это нули и единицы, договоримся о специальном символе-разделителе, например, такой последовательности: 01111110. Теперь, перед началом пакета мы всегда будем посылать эту последовательность, а приёмник будет знать, что получает новый кадр. Тут возникает вопрос, а как поступить, если в передаваемых данных так же встретится подобная комбинация бит? Давайте тогда договоримся, что если внутри кадра нам требуется передать более 5 последовательных единиц подряд, то вместо 111111 мы будем передавать 1111101 – то есть, вставлять нолик после каждых 5 единиц. Приёмник, с другой стороны, так же будет настроен на то, чтобы игнорировать этот ноль. Чтобы не терять синхронизацию, во время простоя приёмник будет постоянно передавать последовательность-разделитель во время установленного соединения.
Когда же требуется установить новое соединение и установить синхронизацию по частоте будем пользоваться следующим соглашением – сначала несколько наносекунд молчания, длительность должна соответствовать как минимум длительности передачи 96 бит (12 блоков по 8 бит или октетов). Это нужно для того, чтобы точно удостовериться, что данные в настоящий момент не передаются. Затем будет посылаться преамбула – 56 бит повторяющихся пар нулей и единиц: 10101010101010101010101010101010101010101010101010101010 – так приёмник сможет точно измерить длительность, с которой будут передаваться биты. Затем мы передадим уже знакомую последовательность начал кадра: 01111110, после чего – наше сообщение.
Мы более-менее успешно справлялись только с одним видом соединения – от одной точки к другой (или по-английски Point-to-Point). А соглашение и правила, по которым мы условились осуществлять передачу, давайте назовём ПРОТОКОЛ. Но тут мы решили организовать компьютерную сеть, состоящую из нескольких компьютеров. Можно, конечно, оснастить каждую пару компьютеров отдельным каналом связи, но проще будет подумать, какие необходимо внести изменения в наш протокол, чтобы можно было бы передавать сообщение по одному физическому каналу на любой из подключённых к нему приёмников.
Для начала необходимо как-то идентифицировать компьютеры в нашей сети. К счастью, каждое приёмо-передающее устройство имеет нечто вроде уникального 6-значного (48 бит) серийного номера, который обычно записывается в шестнадцатеричном виде через двоеточие, например e0:62:0f:1a:02:2d, иначе он называется MAC-адрес (от Media Access Control – управление доступом к среде).
То есть внутри нашего кадра мы теперь будем сначала передавать MAC-адрес приёмного устройства на компьютере-получателе, затем свой адрес (чтобы нам могли ответить), затем укажем подсказку, какие данные внутри, затем – сами данные, после чего – их контрольную сумму (её посчитаем по алгоритму CRC-32, о котором, может быть, я расскажу в другой раз. Тема интересная).
Наш кадр (Ethernet frame) приобретает следующий вид:
Ура, мы заново изобрели протокол Ethernet, одну из разновидностей протокола HLDC (High-Level Data Link Control).
Что передать в качестве типа данных? Давайте пока передадим 0001000 00000000 (0x800), а потом к этому вернёмся.
Тут стоит сказать, что есть одна разновидность HLDC под названием Point-to-Point protocol или сокращённо PPP, которая чуть отличается от вышеприведённой схемы. Поскольку, как следует из названия, он используется для связи вида «точка-к-точке», в поле адрес получателя всегда вносится 11111111 (FF), а в адрес получателя – всегда 00000011 (3). Почему? Так повелось исторически.
Сетевой уровень
И так, теперь, получая по локальной сети кадр данных, приёмник может проверить, а ему ли предназначается данное сообщение. Он сверит MAC-адрес, указанный в кадре со своим MAC-адресом, и, если данные предназначаются не ему – попросту проигнорирует его. Есть, правда, и способ передачи данных на все компьютеры, подключённые к нашей сети. Для этого, в качестве адреса получателя мы должны указать FF:FF:FF:FF:FF:FF – все единицы в двоичном представлении. В этом случае сообщение получит каждое подключённое устройство.
Примечание для параноиков: несмотря на это, при помощи небольших ухищрений данные, предназначенные другой машине, можно просмотреть из любой другой точки сети, эта техника называется «сниффинг», а программы, предназначенные для этого – снифферы или по-умному – анализатор пакетов. Один из наиболее известных и бесплатных Wireshark.
Но что, если у нас несколько сетей? Собственно, само слово «Интернет» это подразумевает. Если всё очень сильно упростить, то интернет – это совокупность локальных сетей, подключённых к крупным магистральным «хабам» (маршрутизаторам, хостам), с прямым соединением:
Допустим, нам необходимо передать наше «Hello!» с компьютера А на компьютер В:
Даже, если мы и знаем MAC-адрес компьютера В (а это в большинстве случаев не так), то при отправке пакета данных с компьютера А, внутри этой сети нет компьютера B, и, соответственно, адресат наше сообщение не получит. Получается, нам необходим какой-то иной адрес, который будет универсальным для любой сети, подключённой к Интернету. При помощи этого адреса, хабы смогут пробрасывать сообщение между различными локальными сетями, зная, к какому именно хабу подключена сеть, где находится компьютер адресата.
Совершенно ясно, что нам необходим новый протокол, который мы так и назовём: Интернет протокол (IP – Internet protocol), а адрес компьютера по этому соглашению – IP-адрес.
В настоящее время чаще всего используется схема адресации версии 4 (IPv4), где адрес состоит из 32 бит (4 октетов), которые записывают в виде десятичных цифр вида 192.168.0.1 или 127.0.0.1. Как нетрудно посчитать, такая схема может максимально адресовать 4 294 967 295 устройств, поэтому сейчас активно внедряется версия 6 (IPv6), в котором на адрес отведено аж 128 бит, вместо 32, чего с лихвой должно хватить на пару ближайших столетий.
Когда на хаб, соединённый сетью А передаются данные для сети B, используя данную адресацию, можно построить требуемый маршрут для передачи. Для этого на каждом из таких компьютеров имеется таблица адресов (таблица маршрутизации или routing table) и номер интерфейса (условно - сетевого адаптера) по которому следует передавать данные на нужный адрес.
Но даже с IP версии 4, поддерживать на каждом хабе адресную таблицу, состоящую из 4 млрд. записей непрактично и вовсе невозможно, когда речь идёт об IPv6. Вместо этого, в адресной таблице (таблице маршрутизации) можно указывать целые группы адресов.
Например, компьютер в сети B имеет IP адрес 47.58.3.83. На хабе «Афина» (названия условны) в таблице маршрутизации указано: пакеты на 47.58/16 отправлять по интерфейсу 2 (на «Аид»).
Сокращение /16 означает любой адрес назначения, где первые 16 бит соответствуют 47.58. Таблица маршрутизации может содержать и уточнение, например 47.58.3/24 → 3 (на «Зевс»). В данном случае пакет будет направлен на хаб «Зевс», потому что чем больше степень уточнения (24 бит вместо 16), тем более высокий приоритет имеет запись.
Но таблицы маршрутизации не решают проблему, как компьютеру в одной локальной сети передать информацию на компьютер в другой сети. Собственно, мы подходим к тому, что внутрь Ethernet кадра, описанного выше, мы должны вложить IP пакет, где будет указано, на IP адрес необходимо доставить информацию.
И ещё – как узнать, какой именно из компьютеров в нашей локальной сети подключён к какому-либо из хабов, то есть, является «шлюзом» (Gateway) в интернет? Если открыть на компьютере свойства сетевого подключения, мы увидим картину, похожую на эту:
Как видно, адрес «шлюза» (Default gateway) обычно настраивается при подключении (Примечание: современные локальные сети могут конфигурировать подключение без участие пользователя). Так же здесь мы можем увидеть загадочное 255.255.255.0 – маску подсети. Она говорит нам о том, что у всех устройств в нашей локальной сети адреса первых 24 бит совпадают. Почему 24 бит? Достаточно посмотреть на эту «маску» в двоичном представлении: 11111111 11111111 11111111 00000000. Единицей промаркированы совпадающие биты в адресах. С такой маской в одной сети может одновременно находиться до 256 устройств. В крупных сетях маска может быть иной.
Эта конфигурация сети говорит о том, что на любой адрес, начинающийся с 192.168.0 можно пересылать сообщения по локальной сети, а информацию, предназначенную для других получателей – отправлять на «шлюз». Но возникает вопрос, адрес «шлюза» – это 4 ничего не значащих для нас цифры, ведь, чтобы отправить что-либо по сети Ethernet, нам необходим MAC адрес для этого устройства. Как водится в сетевом мире, и на это имеется свой протокол, который называется ARP – Address Resolution Protocol (протокол определения адреса).
Простыми словами, в процессе отправки этого запроса по всем компьютерам в нашей сети, мы спрашиваем: «Эй, у кого тут адрес 192.168.0.1?». Шлюз примет это сообщение и ответит аналогичным пакетом, в котором будет указан код операции 2 (ответ) и заполненное поле, где будет указан его MAC-адрес.
На стороне получателя при получении информации извне, шлюз формирует точно такой же запрос, на который отвечает устройство-получатель, сообщая свой MAC-адрес.
Примечание: в жизни всё обычно несколько сложнее, так как IP-адреса внутри локальной сети не являются глобально-уникальными, и в функции шлюза так же входит обязанность по их преобразованию (трансляции). Данная техника имеет название NAT (Network Address Translation).
Теперь, имея физический адрес нашего шлюза и IP-адрес нашего получателя, мы, наконец, можем отправить информацию с текстовым сообщением «Hello!».
Для этого, в уже знакомый нам Ethernet фрейм мы вкладываем IP-пакет. Его структуру можно лицезреть ниже на рисунке (показана структура пакета версии 4). Заголовок пакета состоит из нескольких «слов», длиной 2 байта (32 бит):
Отдельно здесь хочу уделить внимание полю TTL (время жизни) и зачем оно нужно. Если посмотреть на диаграмму с маршрутизаторами чуть выше, не всегда можно надеяться на то, что таблицы маршрутизации на всём пути следования настроены как надо. Предположим, IP-пакет, отправленный с «Афины» на «Аида», но тот, вместо того, чтобы передать его «Посейдону», передал его на «Гермес», который, в свою очередь, имеет правило маршрутизации, предписывающее передавать пакеты обратно на «Афину». Получается своеобразная «петля», и пакет бы передавался так вечно, если бы не «время жизни». С ним, пройдя определённое количество маршрутизаторов, пакет будет благополучно уничтожен (не дойдя до адресата).
Теперь же, заполнив этот «бланк электронного отправления», мы можем приступить непосредственно к установлению связи с компьютером в другой сети, зная, что маршрутизаторы на пути следования этого пакета данных смогут доставить его получателю.
Транспортный уровень
Если вы невнимательно читали, я напомню, что внутрь одного PPP-фрейма может влезть максимум 1500 октетов (байт). Соответственно, если объём передаваемых данных больше этого значения, нам необходимо будет разбить их на несколько фрагментов и упаковать их каждый – в свой IP-пакет. Здесь нас подстерегает ещё несколько проблем.
Мы не знаем, по каким именно маршрутам будут пересылаться наши пакеты, мы не знаем, все ли из них будут доставлены (это называется потеря пакетов или packet loss), и нам никто не гарантировал того, что получены они будут именно в том порядке, что отправлялись.
Данные проблемы могут возникнуть из-за физических повреждений на линиях связи, их перегрузкой, когда с множества компьютеров передаются большие объёмы данных, и маршрутизаторы вынуждены отбрасывать пакеты с низким приоритетом, обновлениями таблиц маршрутизации на пути следования пакетов, отказом оборудования и ещё тысячей и одной других причин.
Ещё одну проблему представляет ситуация, когда между двумя компьютерами одновременно ведётся два или более «разговоров» (например, пересылается файл и осуществляется видеозвонок).
Соответственно, нам нужен механизм (да, угадали – ещё один протокол), который бы позволял нам узнавать, был ли доставлен пакет и повторно отправлять их, если это вдруг произошло, а также определять какой из пакетов к какому из «разговоров» (или соединений) относится.
На помощь приходит Протокол управления передачей или TCP (Transmission Control Protocol), который призван решить все перечисленные проблемы, обеспечивая гарантированную передачу данных по ненадёжным каналам связи.
Пользователям достаточно знать, что, когда устанавливается TCP-соединение, между двумя устройствами как бы пробрасывается «труба», и любой поток данных, вошедших с одного конца, рано или поздно появится на другом, без потерь, искажений и в нужной последовательности (разумеется, если не произойдёт разрыва соединения, но и в этом случае отправитель будет знать, что данные не доставлены получателю).
Примечание: внутри IP пакета вовсе не обязательно должен находиться TCP пакет. Есть и другие протоколы транспортного уровня (UDP, ICMP, но описывать их все будет очень долго).
Проблема идентификации соединения («разговора») решается как обычно в компьютерном мире их нумерацией. При соединении с каким-либо компьютером, мы указываем протоколу TCP номер порта – произвольное 16-битное число, при помощи которого протокол будет определять, к какому именно соединению относится тот или иной пакет. Можно пользоваться любым незанятым портом, однако некоторые номера, всё же, используются под конкретные нужды конкретными протоколами более высокого уровня (да, да, там «наверху» ещё много протоколов). Так, например, всем известный протокол http (с которым работает веб-браузер) использует по умолчанию порт 80, древний протокол Telnet – порт 23, SSH – 22, и т. д.
Далее, протокол TCP разбивает передаваемые данные на фрагменты, так, чтобы «впихнуть» их в IP-пакеты, которые, в свою очередь, будут «упакованы» в Ethernet-фреймы. Но перед этим, фрагменты нумеруются по порядку, и каждому из фрагментов присваивается свой номер.
«Разговор» двух машин по протоколу TCP может быть двунаправленным, то есть, обе машины могут как посылать, так и принимать данные. При получении каждого нового пакета, машина генерирует ответ-подтверждение, которое так же нумеруется. Так обе стороны точно знают, какие данные были переданы, а какие – ещё нет.
Кроме этого, дополнительно в TCP-протоколе предусмотрены 9 однобитовых флагов, позволяющие более точно регулировать процесс обмена данными. Для экономии места я опишу только часть:
SYN – Бит синхронизации, этот флаг устанавливается только на первом пакете.
ACK – Бит подтверждения – у всех пакетов после первого SYN, должен устанавливаться данный флаг.
RST – сброс соединения
FIN – последний пакет.
Общая структура заголовка TCP пакета показана на диаграмме. Обратите внимание, что порядок бит – обратный (младшие биты слева). Так, например, число 100 (0x64) должно быть указано в обратном порядке: 00100110.
Начало сеанса TCP, также называемый «рукопожатие» (handshake), проходит так:
1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. Примечание – в целях безопасности (во избежание злонамеренной подмены номера пакета по пути следования, номер последовательности генерируется случайным образом).
2. Сервер, при готовности принять соединение, запоминает его номер последовательности и посылает клиенту сегмент со своим сгенерированным номером последовательности и установленными флагами SYN и ACK (синхронизация и подтверждение). Если сервер не готов к соединению, отправляется флаг RST.
3. Клиент, получив подтверждение, запоминает номер последовательности сервера и так же посылает пакет с флагом ACK.
Трёхэтапного согласования на практике обычно достаточно для перевода соединения в состояние «установлено» (established). После этого как клиент, так и сервер, могут начинать передачу данных друг другу. Получение каждого пакета подтверждается пакетом с флагом ACK, а так же номер подтверждения – то есть, первоначальный номер последовательности плюс количество полученных байт. Если приходит пакет с номером более ожидаемого, он «буферизируется» – запоминается в специально-выделенной области памяти, которая называется «буфером» в ожидании своей очереди.
Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приёмник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приёмника передающей стороне, в поле «окно» указывается текущий размер приёмного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приёмник. Если приёмник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, пока приёмник не сообщит о большем размере окна.
Когда требуется завершить соединение, его закрытие так же происходит в три этапа.
1. Посылка серверу от клиента флага FIN на завершение соединения.
2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.
Как мы убедились, наши «два байта», которые мы хотели переслать, были в действительности упакованы в своеобразную «матрёшку»:
И это ещё только вершина айсберга. В этом посте весьма поверхностно описаны всего 3 из 7 уровней сетевой модели OSI (Open Systems Interconnections) – де-факто стандарта, связующего огромное количество разнообразных протоколов, которые используются в настоящее время в телекоммуникационных системах. Чтобы описать их все (со всеми протоколами), потребуется издать весьма толстую книгу, написанную сухим техническим текстом без «разжёвывания», поэтому, да простят меня сисадмины и специалисты по телекоммуникациям, если я не сказал чего-то важного, по их мнению.
Как видите, простая поговорка «Просто, как два байта переслать» имеет весьма непростой подтекст.