За последние 14 дней я разработал мессенджер, у которого отличительная черта от остальных мессенджеров — это то, что серверную программы вы контролируете сами. Вы можете скачать исходные коды серверной программы и установить на свой сервер. Клиентская часть доступна для linux на flathub — приложение называется Nem.
Чат со сквозным шифрованием. Прежде чем общаться, нужно обменяться ключами. Для этого есть специальная кнопка с иконкой рукопожатия. После того как оба друга обменялись ключами, они могут общаться. Хочу сразу сказать, общаться могут и без шифрования, но программа без ключа не будет отображать текст и отбросить его. Вот как выглядит интерфейс новой версии.
Как видно из интерфейса, есть кнопка отправки файлов, она расположена слева от строки ввода. Отправка файла — медленная операция, это будет заметно, если отправлять файлы, размеры которых исчисляются мегабайтами. Я стараюсь сделать так, чтобы всё помещалось в 4096 байт. Для этого программа клиент делит по частям весь файл. Вместе с файлом передаются несколько других данных, которые нужны для расшифровки файла. То есть, файл, который передаёт программа — шифруется и в зашифрованном виде отправляется в базу данных. Каждый файл может расшифровать только тот собеседник, кому предназначен файл. Из-за того что в каждом пакете json помещается только 1280 байт зашифрованных данных — скорость загрузки кажется медленной.
Сервер уже может выполнять нужную работу, но документация по api ещё не готова полностью. Там даже авторизация прямо в коде прописана к базе данных. Позже в новых версиях будет авторизация либо в файле настроек, либо через терминал.
Отображения текста — это кастомный виджет. Также я реализовал копирование текста из этого виджета.
Приложение написано с использованием таких библиотек как gtk4, json-glib, openssl.
Также хочу сделать приложение для android, но сначала я хочу закончить с серверной частью, чтобы было нормальное документирование api — а это будет когда я точно пойму что все нормально работает. Приложение для android разработать ещё сложнее, потому что у меня мало опыта в разработке для android. Но если будет открытое api, то возможно найдутся желающие, кто могут сделать приложение самостоятельно. Ну а пока буду делать сам. Надо ещё решить как в android сделать так, чтобы можно было выложить в google play приложение и чтобы в это же время мог принимать самоподписанный сертификат. Так как опыта в этом почти нет, но я с этим сталкивался, будет наверное главной проблемой, когда займусь вплотную android разработкой.
Кому то может не понравиться интерфейс программы, но я почти всё делал сам. Иконку приложения сделал сам и интерфейс программы свой. Иконки кнопок скачаны в свободном доступе или же выбраны из linux. Мне нравиться интерфейс, я вижу дизайн этой программы именно таким, как он представлен.
Но ещё раз повторюсь. Вы сами можете написать клиента для этой программы и если вы это захотите сделать, то желаю вам удачи. Спасибо за внимание.
Комментарии (54)
qrKot
14.10.2021 06:39+820 минут составлял язвительный комментарий, потом удалил...
Вкратце: в проекте есть некоторое количество явно ошибочных решений. Например... всё. Начиная от постановки задачи, выбора языка реализации и протокола обмена до способа поставки конечного приложения - иллюстрация того, как делать не надо (сугубо мое ИМХО, которое, однако, скорее всего, подтвердят 99% специалистов, успевших хоть сколько-то поработать над схожими задачами).
Однако скорее похвалю за энтузиазм. Меня лично на то, чтобы 2 недели в свободное время каждый день колбасить свой пет-проджект, не хватает. Поэтому удачи вам в написании мессенджера (которым я, конечно, пользоваться не буду).
В целом, имхо, перепилите апи, для начала. Раз уж у вас все это на запросах "в лоб" живет (что, конечно, ошибочный подход), то используйте, хотя бы, REST и long-polling.
Вот это:
если будет открытое api, то возможно найдутся желающие, кто могут сделать приложение самостоятельно
несколько противоречит вот этому:
Register
{ "type": "register", "login": "your_login", "password": "your_password" }if a request is valid, then a server answer:
{ "status": "ok" }if a request is invalid, then a server answer:
{ "status": "false" }Открытое API, оно несколько иначе выглядит. Готов поспорить, что при текущем положении вещей "желающие" не появятся.
А еще лучше - покопайте в сторону RabbitMQ/Apache Kafka или gRPC. Если вы разберетесь с тем, как это использовать и вернетесь на хабр со статьей-tutorial'ом о том, как это делается, вам, возможно, спасибо скажут (по крайней мере предыдущий ваш tutorial имел некоторый успех).
xverizex Автор
14.10.2021 09:11ok. А почему интересно выбран язык неправильно? Язык C, GTK4 натив для linux. Из-за этого я смог сделать flatpak пакет и загрузить на flathub. Если нужно будет для windows, то натив для windows store.
qrKot
14.10.2021 15:44+4Ну, на чем вы будете клиента писать, в целом, по барабану, это уже вкусовщина, хотя я бы не назвал GTK4/C кросс-платформенным решением. Там, как и всегда, "есть парочка нюансов".
А вот с сервером. Пока у вас есть сервер, на котором переписываются 3,5 человека - это еще фиг с ним. Но вы же мессенджер пишете, т.е. предполагается, что пользователей будет несколько больше, и архитектурно вещи вроде 10000 сообщений/сек вы рассматривать должны. Да и в целом, у вас должно быть N параллельно происходящих бесед (нет, N мало, пусть лучше будет K).
И тут мы наступаем в следующую яму. Для того, чтобы разрулить 100500 сообщений в секунду, линейного синхронного алгоритма вам не хватит. Соответственно, вам нужно либо смотреть в сторону асинхронности (M:1), либо в сторону многопоточности (1:N), а в идеале (M:N).
Асинхронность в C, насколько мне известно, завезли пока сильно сбоку и с болью, я бы сказал даже, что в pure C ее нет.
Многопоточность - тоже весьма и весьма непростая тема для C-программиста. Ручное управление памятью, помноженное на необходимость синхронизации между потоками - стопудово будет больно, особенно если нет соответствующего многолетнего опыта.
M:N... Ну, как и все остальное, может быть реализовано на C, но "из коробки", насколько я в курсе, относительно честный M:N в виде зеленых нитей есть только в Go (возможно, присутствующие меня поправят). В любом случае, Go для вашей бекендовой задачи подходит однозначно лучше, чем C (на клиент его только не тащите, не надо вот этого), это как пример. В целом, он сильно проще.
А про то, что C "в разы быстрее"... Ну, в целом, при сравнении "в лоб" C однозначно быстрее. Но разница будет вида 30мс/сообщение vs 50мс/сообщение. Кажется, конечно, что это много, но... Но, реальность такова, что пользователи вашего чата эти 20 мс разницы не заметят. Зато они отлично заметят, что при 50 сообщениях в секунду C-шный сервис уже встал раком и вообще перестал реагировать на внешние раздражители, а Go-шный даже не просел по производительности.
Нет, если вы гениальный C-разработчик, один из тех, кто на этом самом C написал этот самый Go, то это не станет для вас проблемой. В остальных случаях вы, скорее всего, не потянете объем необходимой работы "в жало".
Ну и в целом о Gtk4. Сервер чата должен крутиться, предположительно, на сервере. А на "предположительно сервере" Gtk4, предположительно, не будет. Короче, лучше попробуйте это в докер упаковать - это стандарт серверной поставки на данный момент.
zzzzzzzzzzzz
15.10.2021 15:54при 50 сообщениях в секунду C-шный сервис уже встал раком и вообще перестал реагировать на внешние раздражители, а Go-шный даже не просел по производительности
Прям рекламный слоган какой-то... Мне кажется, вы слегка предвзяты.
В любом случае, на сервер данные попадают "линейно синхронно", поскольку через сетевую карту пакетики приходят последовательно. Далее они успешно обрабатываются ядром ОС (сишным же, да?), а вот уже на уровне приложения всё вдруг встаёт раком? Конечно, если там какую-то мега-обработку затеять, то может и встать. Но в реальности там из тормозящего будет что-то типа взаимодействия с файлами или БД, а это от языка не зависит.
А вот Gtk4 на сервере да, лишний.
Хотя вообще я не очень понимаю, зачем нужен ещё один мессенджер, если уже тысячи их. Вроде же тут никакой свежей идеи нет?
qrKot
15.10.2021 20:16Я, скорее, про то, что C "из коробки" ни многопоточности, ни асинхронности не предлагает. Т.е. для того, чтобы эти все прелести реализовать, таки некоторым ненулевым пониманием того, как это устроено, обладать придется. И вот тут мы углубляемся в такую интересную тему, как "100500 доступных для C способов реализации асинхронности/многопоточности" и "как заставить эту хтоническую хрень работать, когда это надо писать ручками, а у меня лапки".
Т.е. я не говорю, что асинхронность/многопоточность на C нереализуема, я говорю, что она реализуема "в ручном режиме" с принятием миллиона "судьбоносных решений" вида "а какую библиотеку мьютексов мы завезем? а, может, свою напишем?"
В целом на C можно написать что угодно. Да, даже чёрт-с-рогами не является чем-то нереализуемым с точки зрения C. В конце концов, изначально реализация тех же самых горутин - это именно с-шная библиотечная функция. Вопрос, который каждый разработчик еще одного уникального мессенджера на "самом быстром в мире языке C" должен себе задать перед реализацией на этом языке мессенджера, это вопрос "а смогу ли я лично реализовать что-то вроде green threads ручками и заставить все это работать в комплексе на своем любимом языке C?".
Если уж вы собираетесь писать на C, вы должны понимать, ЗАЧЕМ вы пишете именно на C, и какие альтернативы/trade-in'ы тут есть. Есть две очевидных "метрики": скорость прохождения одного сообщения и количество сообщений в секунду в среднем, которое способен переварить сервер.
C, что очевидно, отличный инструмент оптимизации первой из метрик, но чат, предположительно, хрень многопользовательская, т.е. вторая из метрик нам кратно более важна. Разница в линейной скорости доставки сообщения нас вообще нас не интересует до тех пор, пока не выходит за разумные пределы. Навскидку до полусекунды - терпимо. Назовите мне язык, не способный за полсекунды распарсить, разобрать, отмаршрутизировать и иными способами надругаться над сообщением!
При этом мне сложно придумать, как заставить такой простой алгоритм "встать раком" на 50-100 сообщениях в секунду. А это именно то, что этот "образчик подлинного искусства" сделал на моей малинке (на чистоту эксперимента не претендую, я не специалист в C).
В общем, в затею реализации вменяемого чата энтузиастом без опыта на C я верю слабо. Язык, все же, для тех, кто понимает, что делает. Хотя... В данном конкретном случае смена языка не поможет.
qrKot
15.10.2021 20:30В любом случае, на сервер данные попадают "линейно синхронно", поскольку через сетевую карту пакетики приходят последовательно. Далее они успешно обрабатываются ядром ОС (сишным же, да?), а вот уже на уровне приложения всё вдруг встаёт раком?
Вот да, например, все именно так... Синхронный алгоритм спрашивает у ядра "дай-ка мне запрос, который из сети пришел" и... и все, стоит и тупо ждет. До тех пор, пока ядро не ответит (а у ядра свои приоритеты, там асинхронность и многопоточность во все поля - умные дяденьки писали), процесс стоит, он просто freez'ится (к слову, тоже достаточно накладная операция - freeze/unfreeze). Он не обрабатывает параллельно 100500 других, он просто замораживается к чертям. Затык в I/O - дисковый ввод/вывод, сетевая подсистема, whatever - 99% проблем производительности, особенно для многопользовательского чата.
domix32
14.10.2021 19:27+1К вышесказанному можно также добавить отсутствие каких-либо тестов — тут и вопрос к валидации запросов и безопасность оных от тех же sql инъекций и огромные пеленки if strcmp в файлах которые довольно проблемно читать.
В качестве альтернативы предложил бы переписать хотя бы сервер на Rust — там и асинхронщина есть, и с многопотоком проблем поменьше и абстракции для этого есть полезные (типа тех же каналов, например) и с безопасностью станет маленько получше и производительность примерно на том же уровне что и у Си при меньшей же головной боли на написание. И тесты можно писать не отходя от кассы.
qrKot
15.10.2021 20:22В качестве альтернативы предложил бы переписать хотя бы сервер на Rust
А, ну да, я ждал этого...
можно также добавить отсутствие каких-либо тестов — тут и вопрос к валидации запросов и безопасность оных от тех же sql инъекций
Вот сейчас вообще не понял, какая связь есть между тестами и валидацией с sql-инъекциями. Реклама какая-то
domix32
16.10.2021 01:06+1А, ну да, я ждал этого...
не то чтобы вас кто-то заставляет. Хабр помнит как люди писали блоги и форумы на asm, ничего, живы.
какая связь есть между тестами и валидацией
Прям напрямую — никак. Однако
- API можно и нужно тестировать. Учитывая что вся ваша документация это кусок README с примерами запросов ответов, который даже нормально нельзя сериализовать в структуры. Мало кто захочет использовать публичные апи построенные на
if json.get(key). - Как уже писали ниже SQL нужно абстрагировать, дабы избежать SQL инъекций. Если велосипедить абстракции самому, то определённо неплохо иметь тесты для того чтобы убедиться, что инъекции не просачиваются.
- Наличие сервера подразумевает, что будут подключаться клиенты и слать всякую дичь. Неплохо иметь fuzzing тесты, чтобы убедиться, что какой-нибудь залетный эмодзи беременного черного трансмужика посреди json (и json ли) не уронил сервер целиком, а ограничился хотя бы одним тредом.
- Сервера мессенджера подразумевают какую-никакую пропускную способность и неплохо иметь тесты производительности, чтобы убеждаться что очередная выкаченая фича не устраивает O(N2) на ровном месте.
Реклама какая-то
Реклама чего, простите?
qrKot
16.10.2021 09:33Реклама чего, простите?
Реклама Rust'а, очевидно.
не то чтобы вас кто-то заставляет. Хабр помнит как люди писали блоги и форумы на asm, ничего, живы.
Очень показательно, к слову, что вы сами ставите применение Rust'а для текущего проекта в один ряд с применением asm'а для той же задачи...
Я не против Rust'а в целом, это действительно хороший язык, отличный инструмент для своих целей. В нише C и C++ Rust смотрится отлично, т.к. он изначально разрабатывался как замена C++ в одном конкретном движке одного конкретного небезызвестного веб-браузера, и если кто-то вдруг начнет писать ядро своей ОСи на Python'е или графический АПИ на JS, или, простихоспади, дивжок браузера на Go, я первый прибегу и скажу "чувак, не майся дурью, попробуй Rust (ну, или C, или C++)".
А в этом пет-проджекте весь этот рокет-сайенс вообще никуда не упирался. Rust - это гребаный скальпель, такой же как и C, только с подсветкой и поддержкой NFC-меток. А человек тут не операцию делает, он дрова рубит. Ему, очевидно, топор нужен, и хрен даже с ним, если без подсветки (потому что топором он, предположительно, сможет успеть порубить нужный ему объем дров до наступления темноты и ночью будет спать, т.е. фонариком так и не воспользуется).
Почему я предложил Go. Думаете, потому что это гениальный совершенный крутой язык? Да ну нафиг: примитивная система типов, текущие во все стороны абстракции, отсутствие дженериков, тупой в лоб синтаксис - это все отличительные черты этого языка. Как язык "с универсальной точки зрения" Go объективно примитивное унылое Г.
Почему же этот уродец вообще родился (да еще и используется!)? Ну, в нем есть горутины и каналы. Если вам рассказывают о каких-то еще "достоинствах языка Go" - это все левые бредни, люди просто "не секут". Green threads из коробки - это его единственная "фича". Т.е. единственное, что умеет Go (и объективно делает хорошо) - это "просирать сквозь себя офигиллиард однотипных неоптимальных примитивных операций в единицу времени за счет 100-процентной утилизации ресурса хоста (M:N)". Это и только это - то, что Go умеет делать, и объективно делает хорошо (как минимум эффективней любого другого общедоступного решения без применения черной магии и познаний в ракетостроении). Но... ой, постойте, это же именно то, что должен делать чат, не?
Во всех остальных случаях (если M:N не основополагающее требование) Go будет, очевидно, не лучшим выбором, поищите что-то другое.
API можно и нужно тестировать
И это тестирование ортогонально выбранному языку, да ведь?
Учитывая что вся ваша документация это кусок README с примерами запросов ответов, который даже нормально нельзя сериализовать в структуры
Вы невнимательны, это не моя документация. Моя, обычно, представляет собой README.md + OpenAPI-спеку.
Мало кто захочет использовать публичные апи построенные на
if json.get(key).Вот это прямо верно. Публичные REST-апи со сваггером пользовать будут, а это - нет. Осталось понять, каким образом Rust связан со сваггером, и какие инструменты, например, для генерации оной спеки, он предлагает. Никаких же, я все верно понимаю?
Как уже писали ниже SQL нужно абстрагировать, дабы избежать SQL инъекций. Если велосипедить абстракции самому, то определённо неплохо иметь тесты для того чтобы убедиться, что инъекции не просачиваются.
Ну, либо взять инструмент, позволяющий избежать этого геморроя, каковой я и предлагаю. Вы же предлагаете написать велосипед, а потом героически обложить его тестами... А тесты, простите, кто тестировать будет?
Ну и в целом, в Java тесты есть, в Go - тоже из коробки. Да, блин, назовите мне язык, где unit-тесты принципиально невозможны! Чем в этом кейсе именно Rust хорош?
Неплохо иметь fuzzing тесты, чтобы убедиться, что какой-нибудь залетный эмодзи беременного черного трансмужика посреди json (и json ли) не уронил сервер целиком, а ограничился хотя бы одним тредом.
Вот это вы проблему "высосали"... Вам же говорят "сквозное шифрование", т.е. для сервера сообщение - это набор байт, который он даже не пытается декодировать... Откуда проблема с эмодзи-то? Или это вы какую-то Rust'овую проблему проецируете? Rust'овые string'и роняют поток на парсинге кастомных эмодзи? Ну, у меня для вас плохие новости - это просто еще один повод не юзать Rust для этого проекта.
Cервера мессенджера подразумевают какую-никакую пропускную способность и неплохо иметь тесты производительности, чтобы убеждаться что очередная выкаченая фича не устраивает O(N2) на ровном месте.
Воу-воу, палехче на поворотах. В Rust уже завезли какой-то инструментарий, позволяющий контролировать сложность алгоритма? Это-то тут при чем? И почему именно тесты производительности, а не профилировщик, shame-on-you?
Если уж мы свели весь спор к Rust vs Go в контексте "простенького сервера чатика", то давайте откровенно поговорим именно о пропускной способности. Go предлагает вполне конкретное решение из коробки - M:N. Он весь целиком, блин, состоит из решения проблемы пропускной способности, больше в нем ничего хорошего нет.
Что в противовес по нашей проблеме предлагает Rust? Продвинутую систему типов? Borrow-checking? Или таки ничего, поверх того, что уже есть в C/C++? Назовите мне фичу языка Rust, нацеленную на решение проблемы пропускной способности многопользовательского чатика, ваш выход!
xverizex Автор
16.10.2021 11:57Я вообще не понимаю причем здесь С и сравнение с другими языками. Если я на С умею писать лучше чем на Go и С++ то я конечно же выберу С. Я знаю больше библиотек на С. А что имеется ввиду о green-thread? В С есть функция epoll_ctl, она накапливает данные, которые должен прочитать клиент, пока наш запрос обрабатывается, как только мы достигаем этой функции в цикле снова, то получаешь порцию клиентов, которые имеют данные в буфере. Мне проще json использовать. запрос должен уложиться в 4096 байт, если json не укладывается, то соединение с данным участником обрывается. Если с json впорядке, то проверяется поле type. например если проверяется register, то дальше проверяется есть ли вообще поля name и password, потом не превышают ли они 16 байт. если всё нормально, то возвращается кодовый статус, которые продвигает данные дальше и там уже обработка происходит с экранированием строк и т.д. Если бы вы код читали, то вопросов бы не возникло. Отдельные потоки только для передачи файлов сделал. Есть еще проблема что если при скачивании файла клиенту отключиться, то сервер упадет, но я пока думаю как это грамотно исправить. Я так понимаю что вы все кто комментируете - не понимаете как в С программировать, а знаете только те, что предлагаете. Но из того что вы предлагаете, я знаю только С++ и Go, и на go уже как год не писал. Так что у меня остался только любимый язык и на нем я хочу дальше писать, чтобы кто не говорил. Я хочу стать мастером.
qrKot
16.10.2021 15:15+1Я так понимаю что вы все кто комментируете - не понимаете как в С программировать
Есть еще проблема что если при скачивании файла клиенту отключиться, то сервер упадет, но я пока думаю как это грамотно исправить
Боюсь тебя разочаровать, бро, но ты тоже не понимаешь, как "в C программировать".
Я вообще не понимаю причем здесь С и сравнение с другими языками.
А вот это плохо. Язык - это инструмент. Их (языков) много, как и инструментов. Если вам нужно вкрутить болт, вы же не берете микроскоп? Ну, собственно, и с языками то же самое.
Так что у меня остался только любимый язык и на нем я хочу дальше писать, чтобы кто не говорил. Я хочу стать мастером.
Вообще не осуждаю, и даже всецело желаю вам успехов в ваших начинаниях. Но мастерство во владении инструментом начинается с понимания, для чего инструмент предназначен. Пока вы, все же, в стадии "если в руках молоток, все вокруг кажется гвоздями".
Я не говорю, что вы хреновый программист. У вас на github драйвер на tp-link t4u,rfcreader и много хороших и полезных вещей. В это я даже не лезу, просто снимаю шляпу, если вы это сами написали (я драйвера писать не умею, да и в целом низкоуровневыми вещами не занимаюсь, преимущественно другой профиль) и оно работает.
Просто вы подход, принятый в разработке драйверов, пытаетесь затащить в высокоуровневую разработку. А оно там не работает. Да и в целом C, как язык описания бизнес-логики, плох. Кросс-платформенный ассемблер из C шикарный, самый лучший, я бы даже сказал. Но на ассемблере, даже кросс-платформенном, высокоуровневые вещи получаются долго, и, чаще всего, плохо.
Если я на С умею писать лучше чем на Go и С++ то я конечно же выберу С.
И зря. C, как, впрочем, и C++ в разработке web-api (а у вас именно оно получается, как бы вы ни упирали на то, что это "чат") если и применяется, то исключительно в виде эзотерических упражнений или дорогостоящих оптимизаций очень специфических узких мест. И это совершенно не случайно.
Да, есть Kolibri OS. Искренне преклоняюсь перед теми, кто это смог написать. Но, блин, по очевидным причинам эта штука в прод никогда не пойдет, и всегда останется шикарной, умопомрачительно и офигенской, но игрушкой из разряда "смотри, чо могу".
А что имеется ввиду о green-thread?
Вот это: https://en.wikipedia.org/wiki/Green_threads
В С есть функция epoll_ctl
Знаю, даже близко "не оно". Эта вещь - это про асинхронность и многопоточность.
Многопоточность (1:N) - может дать вам прирост производительности вашего чатика раз в 10-15 на процессоре с 4 физическими ядрами за счет выноса проблемы ожидания ресурсов на сторону планировщика ОС. Асинхронность (M:1) - кратно увеличит производительность за счет утилизации 1-го ядра.
Лучше бы, конечно, прям вообще (M:N), но, блин, вы выбрали C... Там (1:N) вам такой геморрой способно принести - света белого не взвидите.
Эх, были бы такие инструменты, который "из коробки" (M:N) умеют! А, погодите, есть же такая штука, Go называется! А, это я вам уже советовал...
xverizex Автор
16.10.2021 16:07Боюсь тебя разочаровать, бро, но ты тоже не понимаешь, как "в C программировать".
то есть если человек не знает как решить проблему на С, значит он не разбирается в С. Тогда получается если я придумаю хороший вариант, значит я разбираюсь как программировать на С? ) Вы странно как то мыслите. Получается что если вы сталкиваетесь со сложностью какой то, то вы не разбираетесь в том языке на котором делаете. Раз вы такой уверенный значит у вас задачи простые, где вы не сталкиваетесь с проблемами. То есть вероятно вы пилите сайтики.
qrKot
16.10.2021 19:41+2Раз вы такой уверенный значит у вас задачи простые, где вы не сталкиваетесь с проблемами. То есть вероятно вы пилите сайтики.
Ой, сколько снобизма в какой-то паре строчек, мне аж поплохело...
Чувствуется, к слову, что вы "сайтики" никогда не "пилили", если искренне уверены, что в этой нише задачи исключительно простые, и с проблемами разработчик никогда не сталкивается.
Но в целом, вы практически угадали: пилю сайтики, леплю портальчики обслуживания клиентиков, интегрируюсь со всякими ЦРМочками, ваяю бекендики для мобильненьких и веб приложеньиц, занимаюсь фронтиком на веб-фреймворчиках и чуточку мобильненькой разработочкой, балуюсь брокерочками очерёдочек, пишу торговенькие платформочки с упорчиком на облачковые техноложечки и чуточку пописываю мультиканальчиковую чат-системочку. Все верненько, ничего серьёзненького, ничего сравнимого по сложности с Вашим Чатом!
xverizex Автор
16.10.2021 20:03Да я к тому, что если я столкнулся с проблемой, которую кстати уже решил, но вы почему то сочли что раз я столкнулся с проблемой, то значит я на С не умею программировать. Почему? В таком русле если вы столкнулись с проблемой, то тоже не смыслите в веб разработке. но это ж бред. я тоже хотел веб разработкой заниматься из-за того что там много работы, но понял что мне больше по душе разработка для linux софта. из веб разработки я делал немного веб приложение на чистом js, где можно было в интерактивной режиме создавать uml диаграммы, но так и не закончил, потому что заказчик перестал выходить на связь. а приложение было похоже на dia. вот такое делал. я делал не для заказчика, а тренировался, потому как нужно было на nodejs сделать систему для телеграмма. и для тренировки я хотел сделать сайт, где каждый мог бы на сайте сделать диаграмму и показать остальным, чтобы те помогли ему с построением правильной архитектуры приложения.
qrKot
16.10.2021 21:38Да, насчет "не умеешь в C" - перегнул, сорян. Как минимум, умеешь сильно лучше меня.
Я просто про что: моим первым проектом на заказ, который я делал, будучи сильно моложе, была софтина для микрокредитной организации. Пилил я эту хрень на C++, и она даже работала. Этот "экспириенс" я повторять решительно отказываюсь. Плюсы, как и C, не прощают ошибок, под ворохом каковых я и оказался погребен в конечном итоге.
В вашем случае ошибка всего одна: в позиционировании проекта. Если это "обучающая игрушка", прямо со старта не рассчитывайте, что ей кто-то будет пользоваться. Через 200 тысяч строчек кода, 180 из которых вы выкинете с профессиональным ростом, вы забъете на проект, так и не стабилизировав его. Опыт, который вы получите в процессе, бесценен, но проект вы с 90-процентной вероятностью "не затащите". Просто потому, что между доменом, где C объективно хорош, и предметной областью приложения - 3-4 слоя общепризнаных абстракций, которые вы неизбежно будете вынуждены "родить и устаканить", что фактически неразрешимая задача "в жало".
Если же хочется работающий чатик, детские болячки решаются достаточно элементарно:
Брокер очередей (RabbitMQ, Apache Kafka, ZeroMQ, тысячи их), по которому будут ходить сообщения, который изолирует вас от решения проблемы пиковых нагрузок и необходимости сшивать пакеты по 16кб.
Типовое рест-апи для получения данных подключения, истории сообщений и списка пользователей хотя бы на том же PHP (не, не советую, серьезно, есть языки удачнее).
Передача всего крупного контента ссылками (файл грузится на другой сервер, в сообщении передается тупо урла) избавит от необходимости рожать какую-то вундервафлю для пропихивания гигабайтных файлов через сервер (ему и без этого дел хватает).
Кеширование часто запрашиваемых данных в Redis'е или прочих мемкешах разгрузит бутылочное горлышко с БД.
Эта штука будет работать, и заработает достаточно быстро.
В какой-то части всего комплекса задач чат-движка C смотрится уместно (для оптимизации узких мест). В целом как инструмент решения всего этого комплекса - работа ради работы.
xverizex Автор
16.10.2021 16:44Интересно также что вы такое пишите, что так критикуете чужие работы. вы сами проектируете или пишите на готовом? можете показать личные проекты свои? мне прям интересно что за разработчик такие умные высказывания пишет и приводит только плюсы Go, хотя Go никак не встроен в ядро, а значит пользуется нативными api linux. а если так, то смысла переходить с С на другой язык, просто из-за того что там в коробке уже сделан green-thread это мне кажется что неспособность понять как это сделать в С. мне также кажется
А вот это плохо. Язык - это инструмент. Их (языков) много, как и инструментов. Если вам нужно вкрутить болт, вы же не берете микроскоп? Ну, собственно, и с языками то же самое.
что и здесь вы неправы. есть языки, которые предназначены для чего то определенного, например php. но язык С это язык общего назначения. просто если вы думаете что сервер на С с json обработкой это не профиль С - я вообще не понимаю как вы это можете считать. есть же библиотеки на С, там не только создание json данных есть, но и парсинг входящих данных или вы хотите сказать что это не для сервера сделано? Я сейчас не помню, но я вроде бы должен был написать, что чат только для друзей. вообще одна серверная программа расчитана на 1024 пользователя. но у вас вряд-ли будет столько друзей. я объяснял что чат похож на чат в локальной сети. то есть вы сразу видите всех пользователей, которые зарегистрированы на сервере. ваша проблема в 10000 пользователей уже не обоснована, она вас может волновать, только если вы состоите в какой то крупной преступной организации, где столько людей. но мой чат не для этого. я не хочу чтобы им пользовались преступники. но и производители ножей или оружия тоже не отвечают за то, как будут пользоваться их изделиями. поэтому я делаю чат для друзей, чтобы можно было поставить на свой сервер человек 10 и общаться. и в отличии от jabber, тут не нужно устанавливать какие то дополнительные плагины, чтобы было сквозное шифрование.
qrKot
16.10.2021 20:47+1вы сами проектируете или пишите на готовом?
А где граница? Вот вы на фронте Gtk4 во все поля юзаете - это вы "сами спроектировали" или "на готовом написали"? Вот с этим критерием определимся - смогу ответить.
Интересно также что вы такое пишите, что так критикуете чужие работы
В предыдущем комментарии ответил.
мне прям интересно что за разработчик такие умные высказывания пишет и приводит только плюсы Go
Мне тоже прямо интересно стало, о ком это вы... Если не против, я немного себя "поцитирую":
примитивная система типов, текущие во все стороны абстракции, отсутствие дженериков, тупой в лоб синтаксис
Как язык "с универсальной точки зрения" Go объективно примитивное унылое Г.
Green threads из коробки - это его единственная "фича"
Во всех остальных случаях (если M:N не основополагающее требование) Go будет, очевидно, не лучшим выбором, поищите что-то другое.
Что-то непохоже, что вы про меня. Вы кого в виду имели?
отя Go никак не встроен в ядро, а значит пользуется нативными api linux
Аж чаем поперхнулся... А C, простите, чем-то иным пользуется? Ваш конкретный чатик "как-то встроен в ядро"? Проверил, не, в юзерспейсе работает, т.е. между вашим чатиком и ядром системы находится ровно тот же glibc, что и в случае с любым Go-шным приложением...
просто из-за того что там в коробке уже сделан green-thread это мне кажется что неспособность понять как это сделать в С
А, точно, ну да... Всего и делов-то - реализовать в C green threads... Понять, сначала, что это такое, и резко реализовать!
Вот, например, некий товарищ спросил "а где бы мне green threads под C поискать? Чтобы так же производительно и удобно, как в Haskell'е?"
Почитаем, что там пишут?
just use the GHC runtime, which is a C library, after all). That said, the GHC runtime is 50k lines of C, and uses
epollfor thread scheduling. You'd need an epoll wrapper.does point out criteria, or at least an entrance threshold: the performance and ease of use of Haskell's green threads
Вкратце: Haskell написан на C. Реализация green threads - 50 тысяч строк кода на C, плюс к ней еще надо написать epoll-враппер. Причем вы теряете а) юзабельность, б) производительность...
Там же ссылка на этого товарища, который способен на что-то подобное в C (но не до конца, шедулер не завез). Автор ZeroMQ.
А вот тут - рассказ одного из разработчиков Rust, как он не смог затащить эту фичу в свой язык.
Еще ссылки поискать, или вы продолжите утверждать, что "фигня делов на C грин-треды заюзать, я просто еще не погуглил, что это такое, как только загуглю, так сразу и сделаю".
есть языки, которые предназначены для чего то определенного, например php. но язык С это язык общего назначения
Я вам сейчас не сильно картину мира поломаю, если вот такую ссылку приведу? Процитируем: "PHP is a general-purpose scripting language". Сравним с "C (/ˈsiː/, as in the letter c) is a general-purpose, procedural computer programming language". Прямо так в обеих статьях и пишут: general-purpose language. Ну т.е. я вам и про Go, и про Rust, и про JS могу ссылки дать - все это "языки общего назначения". Вот этот - не, не общего назначения. А PHP - общего.
если вы думаете что сервер на С с json обработкой это не профиль С - я вообще не понимаю как вы это можете считать
Странно, что вы не понимаете. В легкую могу, например. Я, например, понимаю, как вы можете считать, что C для этой задачи хороший выбор: узость кругозора кажется мне отличным объяснением. Обычное несовпадение мнений.
Просто взгляните на статистику. Под формулировку "сервер с json обработкой" подпадает 99,99% всех доступных в вебе ресурсов. Какова доля C в них? "Исчезающе малая" будет, имхо, верной формулировкой. При этом есть такая вещь, как драйвера. В них исчезающе малую долю имеют все языки, кроме C, в совокупности. Или ядра операционных систем - там у C вполне себе солидная доля процентов в 40, навскидку. Или графические АПИ - подавляющее преимущество на стороне C. В игровых движках уже похуже, например.
Ну, в смысле, можно бесконечно говорить о "языках общего назначения", однако бессердечная тварь статистика говорит о том, что ниша у C есть, и локализуется она вообще не в юзерспейсе, о чем я и пытаюсь вам сказать.
есть же библиотеки на С, там не только создание json данных есть, но и парсинг входящих данных или вы хотите сказать что это не для сервера сделано
Да хрен его знает, зачем это сделано. Например, "смотри, как я могу". Какбэ, область применения JSON тоже сервером не ограничивается. Опять же сервер серверу рознь, например. Тот же X11 - вполне себе графический сервер, чо нет.
чат только для друзей
А... Вон оно что... А если я с другом поссорился, и он мне больше не друг - этот кейс ваш сервер как отслеживает? Я в коде это место не нашел...
вообще одна серверная программа расчитана на 1024 пользователя
А это вы как посчитали? Методика какая-то есть? Не, не говорите, я сам догадаюсь: взяли с потолка ближайшее "круглое число".
Один только нюанс в расчетах не учли: 1024 пользователя дают нам потенциальный потолок 1047552 одновременных чатов... Возьмите какое-нибудь более правдоподобное круглое число.
но у вас вряд-ли будет столько друзей
Это, простите, конкретно у меня, или вы в общечеловеческом-абстрактном понимании говорите?)
ваша проблема в 10000 пользователей уже не обоснована, она вас может волновать, только если вы состоите в какой то крупной преступной организации
Вот это даже не знаю, как комментировать... Можно просто в цитатник унесу?
но мой чат не для этого. я не хочу чтобы им пользовались преступники.
Кто же это говорил: "Если ваш софт недостаточно хорош для того, чтобы им пользовались преступники, значит он недостаточно хорош в принципе". Циммерман, видимо, или Столлман. Сейчас не вспомню с ходу.
поэтому я делаю чат для друзей, чтобы можно было поставить на свой сервер человек 10 и общаться. и в отличии от jabber, тут не нужно устанавливать какие то дополнительные плагины, чтобы было сквозное шифрование.
Я вот что-то не понимаю, как связано "для друзей" и "сквозное шифрование"? Вы уж определитесь, пожалуйста...
А, забыл упомянуть, сквозного шифрования у вас нет. И плагины у вас не ставятся... Ну, блин, в jabber хотя бы с
больюплагином можно, а тут вообще никак.xverizex Автор
16.10.2021 21:17как это нет сквозного шифрования, вы код вообще смотрели? если в кратце то вот пример как работает. когда я хочу с вамм пообщаться я предлагаю обменяться ключами. если вы соглашаетесь, то мы обмениваемся публичными ключами. с помощью вашего публичного ключа я могу зашифровать свое сообщение и отправить вам. а вы его можете расшифровать только своим приватным ключом. и все. так как приватный ключ не передается по сети, то всё безопасно. если вы утверждаете что нет у меня сквозного шифрования, то на чем сложилось такое предположение, есть ли доказательства что у меня нет сквозного шифрования? я сейчас улучшил передачу файлов и теперь можно по быстренькому обмениваться файлами, файлы тоже зашифрованы на сервере и расшифровать может только получатель.
Вы говорите что нет серверов с json обработкой. есть. например apache и nginx. но так как они не расчитаны на json, то приходится изать php или js скрипты, которые только лишную память и нагружку создают в парсинге скриптов. а у меня работает как nginx или apache на С со встроенной поддержкой js.
я думаю что сочетание веб сервера со встроенной поддержкой json лучше, чем плодить эти php файлики, чтобы обработать и выдать данные. зачем мне подниматься на такой уровень абстракции, если я могу прям на сервере сделать поддержку json. думаю что у меня даже работает быстрее чем apache и nginx, потому что в этих веб серверах очень много кода и много работы делается, а у меня little производительный серверочек, который делает только нужную работу.
qrKot
16.10.2021 23:13как это нет сквозного шифрования
Совсем нет. Как, например, у WhatsApp нет, и у Telegram нет, вот так же и у вас нет(
Вот в jabber'е плагином, к слову, есть, а у вас нет.
если в кратце то вот пример как работает...
Не, не подумайте, что такое PGP и ассимметричное шифрование я в общих чертах знаю, и даже в курсе, кто такой товарищ Циммерман. И еще знаю, что для того, чтобы это работало, ключами необходимо обмениваться лично и никогда через тот канал связи, которым собираетесь пользоваться. Иначе все ваше шифрование превращается в фикцию.
когда я хочу с вамм пообщаться я предлагаю обменяться ключами. если вы соглашаетесь, то мы обмениваемся публичными ключами.
Вот тут и подвох. На пальцах:
Вы нажимаете на кнопочку "обменяться ключами" и отправляете на сервер свой публичный ключ.
На втором конце человек соглашается и высылает на сервер свой публичный ключ.
В ответ сервер берет свой публичный ключ и присылает каждому из вас.
Вуаля, "ловкость рук и никакого мошенства". Вы отправляете сообщение, сервер его расшифровывает, читает, пакует своим ключом и отправляет вашему собеседнику, не забыв приписать, что это от вас.
"А мужики и не знают".
Ну, короче, нет никакого сквозного шифрования у вас. Фикция это.
есть ли доказательства что у меня нет сквозного шифрования?
У меня есть ваш публичный репозиторий, в котором можно посмотреть, что код, выложенный в нем, совершенно точно не читает мою переписку. С этим у меня все хорошо, это у меня есть. У меня другого нет... Например, уверенности, что на сервере чата, который поднял мой условный друг Вася, крутится именно тот код, который лежит у вас в репозитории.
Вы говорите что нет серверов с json обработкой. есть. например apache и nginx. но так как они не расчитаны на json
Я говорю, что нет...
Но они есть, например, apache и nginx
Но они не рассчитаны (т.е. в них нет)
Н-н-ничего н-не понимаю (с) "Следствие ведут Колобки"
php или js скрипты, которые только лишную память и нагружку создают в парсинге скриптов
Не, там еще немножко, совсем незначительный процент, в пределах погрешности, полезной нагрузки есть. Честно-честно)
а у меня работает как nginx или apache на С со встроенной поддержкой js
Сорян, но вы себе льстите... NGINX - шедевр и образец того, как надо писать на C. Вашему чату, к сожалению, еще надо подрасти.
я думаю что сочетание веб сервера со встроенной поддержкой json лучше, чем плодить эти php файлики, чтобы обработать и выдать данные
Очевидно, от задачи зависит же.
Своеобразная прелесть PHP-скрипта в том, что пока он не исполняется, он просто на диске лежит и не отсвечивает, жрать не просит, например. Т.е. если вам вдруг нужна штука, которая будет запускаться раз в пару месяцев - чо бы нет. В урлу постучали, оно отработало и сдохло (это PHP умеет шедеврально).
А web-сервер со встроенной поддержкой JSON на C - это еще писать надо. А кое-где есть сразу, хороший, производительный и из коробки...
зачем мне подниматься на такой уровень абстракции, если я могу прям на сервере сделать поддержку json.
Вы, видимо, как-то иначе, чем я, понимаете словосочетание "уровень абстракции". Я, например, о том, что прикладной уровень (L7 модели OSI) знать ничего не должен об ограничениях транспортного (L4). Парсер json эти заморочки с ограничениями TLS касаться не должны, он про них и знать не должен. Да и есть/нет там TLS его не касается, например...
думаю что у меня даже работает быстрее чем apache и nginx
Это вряд ли... 10 тысяч запросов в секунду не считается нагрузкой для nginx: пруфы тут.
xverizex Автор
16.10.2021 23:48Вот тут и подвох. На пальцах:
если честно, это какой то бред. чтобы вам объяснить что это бред, я думаю подойдет пример с вами, так вам будет проще понять. но сначала все таки про сервер. как сервер может делать то о чем вы говорите, если в нем нет такого кода? теперь о вас. вот работодатель вас считает трудолюбивым работником, но по вашему оказывается, что вы используете какие то способы со skype, чтобы люди думали что вы работаете за компьютером, а оказывается вы ваньку валяете с друзьями и играете dragon age. вы также постоянно ноете насчет зарплаты, хотя нифига не работаете. вы используете готовые решения, потому что у вас нет времени думать какие то сложные штуки и вам нужно всего лишь создать getter и setter чтобы из одной библиотеки перенаправить в другой класс имя пользователя. и так как вы вообще нереальный сервер представили, как будто у меня такой сервер, который ну прям хитро делает, отправляет всем данные и люди об этом не знают, то могу предположить также бредовую мысль, что вы на js ни одного виджета с отрисовкой не делали, а искали в интернете готовые ( не понятно на сколько безопасные ) решения. просто про несуществующие вещи можно напридумывать всякую дичь, но почему вы это приписываете к моему серверу? докажите такую работу. исходники есть, да. да как можно такое представить?
qrKot
17.10.2021 10:29+1как сервер может делать то о чем вы говорите, если в нем нет такого кода?
Кто сказал, что в нем нет такого кода? Ссылка на github с исходниками? Ну, ссылка на гитхаб подтверждает ровно одно: то, что такого кода нет в репозитории, доступном по ссылке на гитхаб. Никто не в состоянии запретить, например, мне, дописать нужный мой кусок и запустить на моем сервере (мой, блин, сервер, чо хочу, то и делаю). А когда меня будут спрашивать "покажи код", я буду на голубом глазу давать ссылку ну ваш репозиторий на гитхаб. Чуете подвох: один код работает, а другой показывается. И кто мне помешает так сделать? И как проверить?
Вот что есть по этому поводу в вики (т.е. это даже не я придумал, это, блин, миллион раз уже реализовано и опробировано в действии):
Сквозное шифрование предусматривает, что контроль за перепиской осуществляется непосредственно пользователями. Одним из вариантов обхода сквозного шифрования для злоумышленника является захват под свой контроль канала связи между конечными точками, после этого он может попытаться выдать себя за получателя сообщения, чтобы, например, подменить открытый ключ. Чтобы не дать себя обнаружить, злоумышленник после дешифровки сообщения может зашифровать его ключом, который он разделяет с фактическим получателем, или его открытым ключом (в случае асимметричных систем) и снова отправить сообщение. Атаки такого типа принято называть атаками «человек посередине»[1][20] - MITM (Man-In-The-Middle) .
Ну ровно то ведь, о чем я говорил!
Для предотвращения MITM-атак...
<тут много текста, перехожу сразу к сути>
Прежде чем начать разговор, стороны сравнивают свои отпечатки открытых ключей с использованием внешнего канала связи,
Эгегей, блин! Внешнего канала связи! Если обмен ключами или сверка слепков производится с использованием того же канала, через который происходит переписка - у вас какое-то неправильное e2e-шифрование. Товарищ Циммерман (собственно, автор всей этой движухи, съевший на этой теме не один десяток собак) вообще настаивает, что оптимальный способ обмена ключами - на
распечаткеперфокартедискетефлешке при личной встрече.Вся суть "сквозного шифрования" - явный отказ сервера от самой возможности получить доступ к содержимому переписки клиентов. Как минимум, предоставить клиенту способ верификации, позволяющий определить достоверность получателя и отсутствие MitM.
Кнопочка "обмен ключами" в чате - явное противоречие этому принципу. Если клиент чата не позволяет взять ключик, полученный при личной встрече, положить его ручками в нужное место, и использовать для шифрования переписки, утверждения о наличии сквозного шифрования - это ничем не подтвержденная чушь и ересь.
Вообще непонятно, почему вы "защищаетесь от недобросовестных клиентов", и при этом отказываете клиенту в защите от недобросовестного владельца сервера. E2E - это именно про второе, а оно у вас не работает.
qrKot
17.10.2021 11:01теперь о вас
Да, давайте уже обо мне. А то я уже забодался ждать, когда уже наконец мы перейдем на личности!)))
по вашему оказывается, что вы используете какие то способы со skype
Это я где такое говорил?
вы используете готовые решения
openssl req -x509 -sha256 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365#include <json-c/json.h>#include <mysql/mysql.h>Вы, видимо, откуда-то взяли какие специфические специально подготовленные сборки OpenSSL, jsonC и MySQL? И работает это все не поверх GlibC? И не на ядре Linux оно крутится? И во все это не вложены миллионы человеко-часов?
Или какие у вас критерии "готового решения"? Угадать? Язык ведь? Библиотека mysql для C++ - это готовое решение, а она же для C - "неготовое"? Боюсь вас расстроить, но это одна и та же библиотека.
Я использую ровно те же решения, которые используете вы, просто делаю их инструментами, способными эффективней решить задачу.
потому что у вас нет времени думать какие то сложные штуки
Не попал. Потому что я занимаюсь продуктовой разработкой, и рожать самописные костыли для решения проблем, уже решенных десятками способов различными доступными мне инструментами, это роскошь, мне недоступная (да и бессмысленная).
Вопрос в целях. Вам, пока что, важнее "потрахаться с кодом", чем получить работающий чат. У меня приоритет на продукт, "половые сношения с буквами и цифрами" мне уже не так интересны.
потому что у вас нет времени думать какие то сложные штуки
Есть, я по 8 часов день думаю какие-нибудь сложные штуки, мне за это деньги платят. Просто уровень штук у нас с вами разные.
Пока вы думаете над действительно сложной задачей доставки сообщения вариативной длины (нет, я не отрицаю, она действительно сложная, без дураков), я беру инструмент, который позволяет мне абстрагироваться от этой проблемы, решенной неоднократно поколениями программистов до меня, и думать над другой. Например, проблеме гарантированной доставки сообщений вариативной длины неопределенному количеству пользователей при пиковых нагрузках до 10 тыс. сообщений в секунду (не намного проще, чем доставить сообщение через raw-сокет, чесслово).
то могу предположить также бредовую мысль, что вы на js ни одного виджета с отрисовкой не делали
Действительно, мысль бредовая. При этом совершенно не связанная с контекстом обсуждения. Выглядит как попытка оскорбить из разряда "а ты на js писать не умеешь!"
просто про несуществующие вещи можно напридумывать всякую дичь
Ну да, настолько несуществующие, что об этом даже на вики целую статью накорябали со ссылками на десятки обсуждений проблемы...
qrKot
16.10.2021 15:24запрос должен уложиться в 4096 байт, если json не укладывается, то соединение с данным участником обрывается.
Вот поэтому вашим API никто пользоваться и не будет... Вы эту гениальную идею из опыта работы с com-портом почерпнули, признайтесь?
Мне проще json использовать.
Не особенно проще, похоже. Я бы даже сказал, вы его как-то очень сложно используете...
то дальше проверяется есть ли вообще поля name и password, потом не превышают ли они 16 байт.
У вас пароль реально 16 байтами ограничен?
Отдельные потоки только для передачи файлов сделал. Есть еще проблема что если при скачивании файла клиенту отключиться, то сервер упадет, но я пока думаю как это грамотно исправить.
Ну, плохо, получается, сделали...
Так что у меня остался только любимый язык и на нем я хочу дальше писать, чтобы кто не говорил. Я хочу стать мастером.
Мастерство владения инструментом начинается с понимания того, для чего он предназначен. Пока что вы в стадии "если в руке молоток, все похоже на гвозди". Если вы хотите стать "мастером в C" - ну, написание чатиков в этом не поможет...
xverizex Автор
16.10.2021 15:45Вот поэтому вашим API никто пользоваться и не будет... Вы эту гениальную идею из опыта работы с com-портом почерпнули, признайтесь?
а точно. я когда с крипто биржей работал, она постоянно мне в ssl по 4096 байт отправляла и я тогда подумал что это максимум для ssl. но щас проверив, я увидел что максимум можно 16384 байта отправить за раз. ну это я исправлю и тогда отправка файла будет быстрее, что меня порадовало.
qrKot
16.10.2021 21:09Да-да, конечно:
Максимальный размер сетевого пакета для шифрованных соединений составляет 16 383 байта
Но, блин! Еще раз читаем: максимальный размер сетевого пакета! На JSON'ку-то откуда ограничение взялось??? Вы вот сюда сходите, что ли.
Каким образом ограничение OSI касается JSON'ки, находящейся выше L7 (уровня приложения)? Ну, давайте, что ли, уж ограничения кадра применим - 1492 байта потолок? А чо, он тоже где-то там ниже уровнем есть...
Просто определитесь, вам "работающий чат для друзей" нужен, или "разобраться на самом низком уровне, как это работает"?
Если второе, то вы все делаете правильно (кроме ожиданий, что этим кто-то будет пользоваться), и я вам в этом помогаю (прямо говорю: "у вас проблема какая-то, так не делается, разберитесь с тем, как N пакетов сшить в 1 JSON'ку. Когда разберетесь, покажу вам, что такое SAX-парсер, и как он помогает вам не париться по поводу размера JSON-ки").
Если первое, то я вам опять прямо говорю: хрен у вас чего получится с таким подходом. Высокоуровневые задачи гораздо лучше решаются высокоуровневыми инструментами.
xverizex Автор
16.10.2021 21:37мне хватило нескольких секунд, чтобы понять, что размер в 16К с одним json будет правильней. ну вот смотрите. что если бы мой сервер принимал и собирал несколько данных в один json, тогда в таком случае можно сделать атаку такую, что будут бесконечно передаваться данные, пока не исчерпается ресурсы компьютера. это легко понять. как вы будете проверять данные на размер, если json еще не пришел полностью? json поля можно проверить, когда json полностью построен и распарсен. тогда я могу гигабайты слать и не закрывать json и всё. да не. вы наверное просто не думали об этом. но я в основном сразу думаю о том как можно обойти что-то. так что я считаю правильным решением ограничить в максимальный размер принимаемых данных. я в документации прочитал что максимум на tls1 и sslv3 может принять 16К. так что сделал такое ограничение. если json объект не полный, то всё, отбрасываем и закрываем соединение. сразу видно, если пользователь нормальный, то будет правильные данные слать, если злоумышленник, то будет обрыв соединения. там никак вообще не обманешь. только если есть уязвимость в json-glib, ой, не в json-glib, а в json-c.
qrKot
16.10.2021 22:31мне хватило нескольких секунд, чтобы понять, что размер в 16К с одним json будет правильней.
Мне потребовались несколько более долгие изыскания, чтобы убедиться, что этого недостаточно для того, чтобы скопи-пастить и отправить одним сообщением мой любимый отрывок из поэмы А.С.Пушкина "Скупой рыцарь".
Ну, в целом, выглядит как "проблемы индейцев шерифа не кузюкают" и "если пользователям что-то не нравится в чате, нужно менять пользователей".
ну вот смотрите. что если бы мой сервер принимал и собирал несколько данных в один json, тогда в таком случае можно сделать атаку такую, что будут бесконечно передаваться данные, пока не исчерпается ресурсы компьютера.
Ну да, все верно, задача несколько более комплексная, чем то, что можно решить за "несколько секунд". Но мы, вроде как, на то и программисты, чтобы решать комплексные задачи. И вот тут мы можем смело возвращаться к разговору о языке общего назначения C... Назвался груздем, полезай в кузов). В "более других языках общего назначения" эта проблема в целом решается достаточно незначительными телодвижениями. В том и прелесть C, что у вас есть свобода решить ту же самую проблему еще раз, своим единственно-правильным методом.
как вы будете проверять данные на размер, если json еще не пришел полностью?
Считать пакеты?
json поля можно проверить, когда json полностью построен и распарсен
Ну неправда же! SAX-парсер, гуглите на здоровье. То, что его "из коробки" не завезли в C, ну, блин, зато "настоящий язык общего назначения".
тогда я могу гигабайты слать и не закрывать json и всё
Ну да, это так и устроено: один из пользователей может оказаться (и неизбежно окажется) злобной сволочью. Сделать "одинаково плохо всем" от этого не начинает казаться хорошей идеей.
да не. вы наверное просто не думали об этом.
Знаете, подумал...
но я в основном сразу думаю о том как можно обойти что-то.
Не более нескольких секунд думаете?)
так что я считаю правильным решением ограничить в максимальный размер принимаемых данных
Стопудово пользователи с вами не согласны. Хотите, чтобы чатом кто-то пользовался, решайте проблему.
я в документации прочитал что максимум на tls1 и sslv3 может принять 16К.
Кроме документации tls1.3 прочтите все же документацию про JSON. Там этого ограничения нет. Более того, 2-3 мегабайтные json-ки вполне себе в ходу, и прямо даже поверх TLS1.3, лично видел, честно-честно.
сразу видно, если пользователь нормальный, то будет правильные данные слать, если злоумышленник, то будет обрыв соединения
То вы меня в преступную группу записываете за чат более чем на 1024 человека, то злоумышленником за ностальгические чувства к некоторым избранным отрывкам из Пушкина клеймите. У вас сообщение закончится до того, как я отрывок, который на память помню, до середины допечатаю(
domix32
16.10.2021 23:04Я вообще не понимаю причем здесь С и сравнение с другими языками.
Потому что в текущем виде вы пытаетесь разделывать тушу быка при помощи хирургического скальпеля и при попытке достать из черепа мозг закономерно сталкиваетесь с проблемами.
Вам нужна асинхроность для практически всего — база данных, сеть, внутренняя обработка состояний клиентов.
Вам нужна адекватная обработка ошибок — коды возврата определенно не спасают от падения сервера, который по своей сути должен быть бронебойным. Отсюда
Вам нужно логирование. И нет, не printf в какой бы то ни было ипостаси.
Вам нужны абстракции- уход от сырых запросов в БД к чему-то ORM-подобному — иначе зачем вам шифровать хоть что-то если клиент может скомандовать
DROP TABLE * - уход от сырых сетевых подключений к инстансам сессий клиентов и стриминг менеджерам.
- уход от голых epoll_ctl и прочих к тредпулам и оркестраторам асинхронных исполнителей.
Вам нужно тестирование, чтобы все это дело компоновать между собой и не ловить потом странных артефактов повсеместно.
На Си такое конечно можно организовать, но все это будет работать через такую-то матерь. Поэтому и предлагалось взять что-то более подходящее для задачи, потому что в текущем виде оно уже имеет кучу проблем, которые давно решены в других языках.
Ну, а так, удачи точить мастерство. И это без сарказма.
- уход от сырых запросов в БД к чему-то ORM-подобному — иначе зачем вам шифровать хоть что-то если клиент может скомандовать
qrKot
16.10.2021 19:32UPD по моему комментарию:
async/.awaitis Rust's built-in tool for writing asynchronous functions that look like synchronous code.Rust таки предлагает из коробки async/await, что таки делает его более осмысленным выбором для реализации сервера чата, чем C.
В связи с этим за эту часть моего пассажа:
Что в противовес по нашей проблеме предлагает Rust? Продвинутую систему типов? Borrow-checking? Или таки ничего, поверх того, что уже есть в C/C++? Назовите мне фичу языка Rust, нацеленную на решение проблемы пропускной способности многопользовательского чатика, ваш выход!
приношу свои искренние извинения, был молод, горяч, в этом месте сильно неправ. Коммент оставляю как есть, пусть мне будет стыдно. Прошу прощения за этот кусок.
Но только за это! (с) шевалье д'Артаньян в исполнении Михаила Боярского.
Остальную часть аргументации по-прежнему считаю ошибочной.
domix32
16.10.2021 22:20Остальную часть аргументации по-прежнему считаю ошибочной.
Как-то вы меня сразу в крабовые культисты записали. Ржавая часть была в одном абзаце в первом комментарии, все остальные принципиально language agnostic и никак не агитировали использовать раст. джава, го, шарп тоже могут умеют практикуют, но пункты про тестирования все также остаются валидными и для этих языков.
Вы невнимательны, это не моя документация.
Да, не обратил внимания что отвечал на автору поста и телега про доку в ридми она от меня пришла не по адресу.
И почему именно тесты производительности, а не профилировщик, shame-on-you?
Ну так профилировщик нужен для того чтобы выяснить что именно тормозит в уже написанном, а тесты нужны для того чтобы оценивать просел ли перфоманс после изменений. Тут на хабре есть вполне достаточно статей про то как что-то переписывали с Х на Y или просто меняли часть кода и получали прирост производительности. Каким образом узнавали улучшения? Конечно же при помощи тестов. Для больших комплексных штук с несколькими командами такое делается в CI чтобы оценивать performance triage. Заодно могу порекомендовать почитать сайт accidentally quadratic и как некоторые из проектов обкладывали пофикшенные кейсы тестами.
для сервера сообщение — это набор байт, который он даже не пытается декодировать
То есть вы хотите сказать, что шифрованные джсонки приходят на сервер и просто кладутся в базу и никак не обрабатываются? Звучит как бред. На одном из этапов необхдимо понимать что внутри json и это именно тот самый этап когда что-то может пойти не так. Я не слишком всматриался что там за либа для json и как конкретно обрабатываются шифрованные пакеты и не могу сказать насколько она защищена от невалидных штук типа мусора из /dev/urandom и бНОПНЯ в теле json. Именно поэтому есть пункт про фаззинг.
xverizex Автор
16.10.2021 22:29сервер никак не обрабатывает сообщения, то есть можно без шифрования даже писать, но desktop клиент отбросит сообщения. сервер смотрит, если пользователь не онлайн, то добавляет его в таблицу для ожидания. и все. максимум пакет за раз может быть 16384 байт. никакие apache kafka и прочее не нужно, если они позволяют собирать более 16384 байт. мне нужно чтобы сервер мог быстро получить байты и обработать, а не так, что каждый запрос по секунде обрабатывать. поэтому в 16384 байт вполне подходит для того, чтобы обработать, если сообщение в json не поместилось, то соединение обрывается. я точно не знаю, но подразумеваю что все эти новомодные штуки типа apache kafka жрут много памяти. я же стараюсь сделать менее требовательный к памяти. чтобы можно было разместить на дешевом компьютере vps или как там называется. там есть еще моменты в коде сервера, где требуется 30 мб памяти, но я позже уберу эту возможность.
domix32
16.10.2021 23:14То есть вы хотите сказать что у вас там оракул на сервере, который знает в какую руму клиент хочет зайти? И логин пароль тоже угадывает для каждого подключения? Внезапно выяснение таких вещей и есть обработка сервером. Чтобы прочитать данные ему придётся ещё и расшифровывать это. Учитывая что обрыв соединения роняет сервер я не удивлюсь если найдутся и тут проблемы. До интеграции кафки тут еще копать и копать.
qrKot
16.10.2021 22:39Как-то вы меня сразу в крабовые культисты записали.
Сорян, рефлекс(. Привык к достаточно агрессивному пиару Ржавчины от истинных адептов, призывающих переписать на нем все, даже небо, даже Аллаха, даже WordPress. False positive получилось(.
В language-agnostic контексте вы выглядите очень позитивным и разумным человеком).
То есть вы хотите сказать, что шифрованные джсонки приходят на сервер и просто кладутся в базу и никак не обрабатываются?
Не, не совсем так. Там приходит json-ка с полями "от кого", "кому", "тип сообщения" и "дата". Вот дата - закодированный набор байт, который таки да, кладется в базу. Сквозное шифрование, сэр!
xverizex Автор
16.10.2021 22:48Там приходит json-ка с полями "от кого", "кому", "тип сообщения" и "дата". Вот дата - закодированный набор байт, который таки да, кладется в базу. Сквозное шифрование, сэр!
таки сквозное. никто кроме получателя не расшифрует. так что данные могут быть безопасно храниться. а ты по-любому должен раскрывать кому отправляешь данные, сервер должен как то понимать кому слать сообщения.
qrKot
16.10.2021 23:15таки сквозное
Таки нет. Вы ключами обмениваетесь ровно через тот сервер, который "честно-честно не умеет читать ваши сообщения". Т.е. соединение изначально скомпрометировано, by design.
domix32
16.10.2021 23:25Там еще про логин пароль выше что-то писалось, да и регистрация клиента на конкретном сервере как-то происходит так или иначе. Так что найдется мест куда можно скормить ереси. Ту же дату как-нибудь по хитрому сформировать, чтобы оно распарсилось в пару мегабайт из памяти сервера, например. Или heartbleed оформить. Или представиться, как какой-нибудь
человек из бездны. Было бы желание, а способ найдется.И̵̴̭̞̫̼̼̣̬͖̮̓̈́ͬ̌̐͗̋̍͌̊̽͋ͮͫͨ̑̚͘͢͞в̰̝̺̝͍̭̟̟̖͕͎̞̥̳̬͖͉͈̓͋̍͐͌̀ͨ̓̉ͨ̿ͥ̂ͦ͛͞а̶̻̞̘̜͈̦̼̬̗̯̙͍̻͚̖̭̪͑͊̏̍̋ͧ͒̕͢ͅн̓̂̀̅̑̐̒͐̂̅̆̒̈̑̑ͭ̎̚͏̭͈̣͈̲̣́́͡о̶̨̮̗͙̥͉̥̙̭̱̺̩̞̠͇̙̽̅͆̐̽ͤ̉̇ͯ̀̆̚в̸̧̰̮̲̮̥̞̦͍̩̤̘͉ͪ̐̌ͧ̇͆̈́ͮ̇̒̕̕ ͓̪̺͖̟̈͆͆̿̕͡И̸̗͎̠̫ͣ̏̎̑̏̄̈́̉̍̽͗͋̚̕͞вͩ̇̈́ͣ̎ͣͥͥ̋̽̓͋̒̅͊҉̸̸͎̪͓̲̻͍͇͙̭̪̦͕а͛͋ͣ̏͐ͯ͗̉̆̎̈͆͏̩͓̦̠̀͟нͥͥͤ̍ͣ̐ͩ͑̐͐ͪͦ̈́ͣ̇̌ͣ̾͊҉̵͙͓̥̮̺͉̜͞͝ ̴̧̡̺̰͍͉̟͔̞̂͒͐̐ͮͭ̿̆̆́̚ͅͅИ̶̱̙͎̲̼̥̙͊ͭ̆͋ͤ̒ͪͩͪ͂ͥ̿ͯ́͢в̸̡̡͈̫̺̆̓̅̓ͨ̾͋͒ͣ͆̆̓͊ͬа̢̧̇̔̉̇͏̤̩̺̩̣̳̭͕̮̪̜̱̤̮͙̦н̴͈̰̠̺̯̙͖̱̻ͥ̅̂ͭ͑̚̕͜͟͝ͅо̡̡̻͖͚͔͎̺͎̙̩͔̆͌̉̽͆ͩ̃͐̾̈́͐ͬ̕͟͟в̸̟̩̻̘̭͍͔̝̹͓̤̱͔̭͙͈͍̀͒ͫ͌͗ͦ̆̍̆͠и͌ͤ́͌͡҉̶͎̘̹̦͎̥̳ͅч̅ͧ̌̈̉̏̔ͪ͆͑̆̕͡҉̡̱̠̩̼̣̗̬̞̪̭͓̩̣ͅ
xverizex Автор
16.10.2021 23:51так по-вашему вы тогда и сами пишете небезопасный код. будет желание и ваш код взломают. вы хоть раз формировали дату по хитрому, чтобы можно было распарсить в пару мегабайт? aes шифрует 255 - 11 байт всего. в сообщение получается 256 байт. как вы хитро распарсите? я устал короче общаться с вами. мне уже не интересно.
- API можно и нужно тестировать. Учитывая что вся ваша документация это кусок README с примерами запросов ответов, который даже нормально нельзя сериализовать в структуры. Мало кто захочет использовать публичные апи построенные на
scorpka
14.10.2021 06:40+3Лайк поставил, но пока что не вижу, чем приложение лучше/будет лучше джаббера
dolfinus
14.10.2021 09:27+4у которого отличительная черта от остальных мессенджеров — это то, что серверную программы вы контролируете сами. Вы можете скачать исходные коды серверной программы и установить на свой сервер
Rocket.Chat, Matrix и другие open-source мессенджеры непонимающе смотрят со стороны
ViacheslavNk
14.10.2021 14:30Из описания не понятно, как реализована зашита от MITM, на случай если к владельцу сервиса пришли из ФСБ/АНБ/просто бандиты и взяли под контроль сам сервер.
qrKot
14.10.2021 15:58Из исходников понятно, что никак. Тут только другой вопрос, какая связь между MitM и ФСБ/АНБ/Бандитами в вашем офисе? Паяльник между булками не попадает в классификацию Man-in-the-Middle, это что-то вроде SIbB - Soldering-Iron-between-Buns.
Да и в целом, вы на полном серьезе собираетесь этот чудо-чат использовать в бизнесе? Ну, у меня для вас плохие новости...
ViacheslavNk
14.10.2021 16:20Нет я не собираюсь использовать данный чат, но всегда, когда заявляется о сквозном шифровании, возникает вопрос каким образом реализована зашита от MitM в случае если сервер взят под контроль злоумышленниками, или любопытный админ хочет почитать. Даже для студенческой поделки нужно хотя бы обозначить этот вопрос, например, хеш публичного ключа и является логином/id пользователя.
А насчет вопрос связи между MitM и паяльником, в теории реализация может быть такой, что без знания пароля конкретного пользователя которым зашифрован приватный ключ, прочитать уже существующею переписку невозможно, даже с паяльником, но можно прослушать последующею, если не принято соответствующих мер.
qrKot
14.10.2021 18:40всегда, когда заявляется о сквозном шифровании, возникает вопрос каким образом реализована зашита от MitM в случае если сервер взят под контроль злоумышленниками
Ну вы скажете тоже, "заявляется". О "сквозном шифровании" не заявлял только ленивый. WhatsApp заявлял, Telegram заявлял, Apple заявлял, хотите, я тоже заявлю?)
Вопрос, "а есть ли действительно там сквозное шифрование" должен задаваться, имхо, до вопросов о MitM и SIbB. Потому что если оно действительно есть, эти два вопроса отпадают сами собой, иначе это шифрование какое-то "не сквозное".
в теории реализация может быть такой, что без знания пароля конкретного пользователя которым зашифрован приватный ключ, прочитать уже существующею переписку невозможно, даже с паяльником
Ну вот неправда же. Паяльник - одно из самых (если не самое) эффективных средств криптоанализа. Если в вашей ситуации он, почему-то, не работает, вы его, видимо, "просто не туда вставляете".
но можно прослушать последующею, если не принято соответствующих мер.
Если пользователь A написал сообщение пользователю B, и пользователь B его смог прочесть, значит без участия пользователя A это сообщение прочесть гарантировано можно, и MitM и сквозное шифрование тут не при делах. Вообще не при делах.
Если при этом третье лицо получило доступ к этому сообщению (неважно, через какое количество промежуточных звеньев, третих, четвертых и более лиц оно прошло) без ведома первых двух, то вот это уже вопрос к сквозному шифрованию, т.к. ситуация однозначно свидетельствует о 2 возможных вариантах: либо оно недостаточно стойкое, либо, что вероятнее, его просто нет. Хотя, какая уж разница, это равнозначные ситуации.
toxicdream
14.10.2021 15:25+2Правила проектирования ПО:
0. посмотри как сделано у других.
...
Хотя автор кажется пропустил вообще весь процесс проектирования. Сразу хуяк-хуяк...
dynamicult
Как обстоят дела с корованами?
katelinlis
в следующем обновлении