Synapse TCP/IP client and server

[Sharfik]

На соседнем FPC форуме есть одноименная тема с примером работы клиент-сервера.
https://forum.lazarus.freepascal.org/in ... 677.0.html
Поскольку для меня это новая задачка, пример стал весьма полезным. Но при детальном изучении стал утыкаться в графическую ориентированность и странную реализацию основного для примера модуля.
1) Все ориентировано на GUI. Не о каком запуске в качестве сервиса и речи быть не может в изначальном варианте. Админка и есть само приложение сервера.
2) Автор жестко связал клиент и сервер на уровне классов, это жесть.
3) Все переменные и объявления организованы так, что при попытке разделения классов придется много чего перестраивать, выводить новые свойства. Иначе при разделении клиента и сервера на разные юниты важные переменные станут не доступными.
Теперь то что я не понимаю:
1) Список пользователей он хранит обычным TStringList, а список потоков этих же соединений - ThreadList. Где логика?
2) Наверно пока самый главный вопрос для меня, где нужно мнение тех кто опыт имел создания клиент-сервер. Что за фигня? Запущен сервер, каждое соединение создает свой отдельный поток. Но чуть что, обработка событий, даже проверка логина/пароля все через синхронизацию перенаправляется в основной поток приложения. Может я что то не понимаю, но это повышение шанса уронить сервер на мой взгляд. Плюс замедление выполнения операций при скоплении подключенных клиентов. По хорошему же надо обработку сообщений отправить в потоки?
3) Третье вытекает из второго, при расширении. Если цеплять SQL соединение, то что лучше инициировать соединение на каждом запросе от клиента или держать соединение открыты для потока клиента в принципе?

[DedFrend]

сама по себе библиотека synapse нисколько не gui ориентирована. Писал я на ней и клиентов и сервера, правда без тредов. А синхронизация с основным потоком вполне может быть связана с gui. К окнам ты имеешь право обращаться только из основного потока.

[Sharfik]

сама по себе библиотека synapse нисколько не gui ориентирована. Писал я на ней и клиентов и сервера, правда без тредов. А синхронизация с основным потоком вполне может быть связана с gui. К окнам ты имеешь право обращаться только из основного потока.

Что она не связана с gui это понятно, надеюсь что и не привязана к конкретной ОС. Не пробовал делать под linux делать пока ПО.

правда без тредов.

Не знаю что это

А синхронизация с основным потоком вполне может быть связана с gui. К окнам ты имеешь право обращаться только из основного потока.

Просто это узкое место производительности

[DedFrend]

тред - мне больше нравится в качестве перевода thread. Следую Столярову

[Sharfik]

тред - мне больше нравится в качестве перевода thread. Следую Столярову

Вообще там звук Ф, а не Т. Тред это тогда тоже самое что ДХСП, за которые отдельные айтишники даже разговаривать не станут. И будут правы.

[Снег Север]

ДХСП, за которые отдельные айтишники даже разговаривать не станут

Я, тех, кто "разговаривать не станет" сам немедленно посылаю на Х.

[Shleps]

тред - мне больше нравится в качестве перевода thread. Следую Столярову

Вообще там звук Ф, а не Т. Тред это тогда тоже самое что ДХСП, за которые отдельные айтишники даже разговаривать не станут. И будут правы.

Вы хотели сказать ДХЦП? динамик хост конфигурэейшн протокол?
онтопик - я так понял, что синапс это для тех, кому побыстрее и попроще, у кого сокеты не асинхронные, а блокирующие и поэтому многопоточность нужна, чтобы обмен приложения с одним клиентом не тормозил обмен с другими клиентами (а заодно и гуи. просто гуи это переживет, а соединение может и отвалиться по таймауту).
А что сложные вещи происходят в основном потоке.... это не столь принципиально. все равно если обмен с одним клиентом изменяет какие-то общие для всего приложения вещи - эти изменения надо семафорами прикрывать.

[Сквозняк]

Просто это узкое место производительности

Если бы. Когда лазарусную форму с окнами используешь из неосновного потока, то сыпятся ошибки, из-за них, а не из-за производительности приходится выделять главный поток.

[Sharfik]

Вы хотели сказать ДХЦП? динамик хост конфигурэейшн протокол?

Я тут один, не раздваиваюсь
ДХСП- DHCP.

Я, тех, кто "разговаривать не станет" сам немедленно посылаю на Х.

Язык нужен для общения, если люди занимаются херней и придумывают новые слова они некому пользы этим не делают. Скорее помогают деградировать следующему поколению. Есть правила чтения аббревиатур в английском языке, есть Google переводчик. Этого вполне достаточно чтобы либо использовать корректное обозначение вещей, либо корректно перевести его на свой язык используя терминологию. В IT достаточно простые обороты слов используются, и базовых знаний английского тут достаточно. Все остальное от лени.
Если брать разговор выше, то в учебниках используется термин "поток", а не "тред". Зная базовые основы мне, не специалисту IT, вполне легко слушать иногда лекции и выступления по IT тематике. Если бы там использовался базарный диалект, где каждый называл как ему в голову взбредет вещи, то это было бы жестью.

Добавлено спустя 7 минут 52 секунды:

Если бы. Когда лазарусную форму с окнами используешь из неосновного потока, то сыпятся ошибки, из-за них, а не из-за производительности приходится выделять главный поток.

Вот и развлекался, переделывая пример в рабочее приложение с внешним админским клиентом.

онтопик - я так понял, что синапс это для тех, кому побыстрее и попроще, у кого сокеты не асинхронные, а блокирующие и поэтому многопоточность нужна,

Я пробовал разобраться с indy библиотекой, но это жесть какая то. Адекватного примера не нашел, а по статьям в сети получалось что после посылки пары сообщений между клиент-сервером все зависало безбожно. Подозреваю что портирование на FPC не идеальное. Тут попался пример этот с Synapse и хоть что то рабочее получилось сделать.

[Shleps]

Вы хотели сказать ДХЦП? динамик хост конфигурэейшн протокол?

Я тут один, не раздваиваюсь
ДХСП- DHCP.

Ок.
Сетевики протокол DHCP по-русски транслитом произносят именно "дэхацэпэ".
Касательно смешения в русском понятий stream, thread и flow в поток" - ну знать бы заранее - перевели бы "сетевые" термины, как "поток", а поток команд - как "нить". а теперь только громоздкое уточнение контекста на грамотном русском (типа "поток команд") или транслитить thread, так чтобы по телефону понятно было.

В IT достаточно простые обороты слов используются, и базовых знаний английского тут достаточно.

эээээээ видать не доводилось по телефону индусу объяснять разницу между IDE, EDA и IDE который до SATA
Или UTP STP RSTP PVRSTP.

А ещё у Cisco, D-Link и 3Com один и тот же термин разные вещи означать может.
у один trunk - это link aggregation, а у других - линк по которому ходят несколько разных VLAN

Я пробовал разобраться с indy библиотекой, но это жесть какая то.

А Инди как раз умеет работать асинхронно (т.е. неблокирующие сокеты) и именно поэтому там не обязательно многопоточность и там жесть.
Сам не осилил. Юзаю Синапс. совсем корректно не получается, за образец свой сетевой код не порекомендую - часто вылетает, но тем не менее стоит в продакшене и принимает десятки соединений в секунду от разных машин.

Добавлено спустя 11 часов 52 минуты 14 секунд:

Если цеплять SQL соединение, то что лучше инициировать соединение на каждом запросе от клиента или держать соединение открыты для потока клиента в принципе?

цеплять Sql - имеется в виду, что приложение само идёт на SQL-сервер по порту 1433?
или tcp-клиенты обращаются к tcp-серверу, который работает с БД через компоненты?

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


Если запросы часты и мелкие - то держать сессию.

Добавлено спустя 6 минут 57 секунд:
Вот за FIN_WAIT, FIN_WAIT2 и TIME_WAIT я бы разработчикам TCP руки оторвал.
А разработчикам линукса - за то, что не дают MSL руками крутить в отличие от FreeBSD.

https://blog.kireev.pro/2017/07/%D0%BF% ... time_wait/

[Sharfik]

Сетевики протокол DHCP по-русски транслитом произносят именно "дэхацэпэ".

Произносится так как написать - по звучанию букв в английском Ди-Эйч-Си-Пи.

цеплять Sql - имеется в виду, что приложение само идёт на SQL-сервер по порту 1433?
или tcp-клиенты обращаются к tcp-серверу, который работает с БД через компоненты?

От клиента запрос, сервер сам с сервером SQL общается, и отдает результат обратно. Фактически смотрю как делать промежуточное звено, которое поддерживает адекватное соединение и помогает передавать файлы.
Пока сделал каждому клиент-потоку на сервере свое постоянное соединение с SQL сервером. вроде работает, если не часто. Когда каждую секунду обновление списка пользователей клиентом запрашивается вылетает соединение.

[Shleps]

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

вылетает соединение по TCP между клиентом и сервером или сервером и SQL?
мне кажется, что происходит второе. потому что "если не часто, то работает" - т.е. пока в работе ровно 1 клиент - все хорошо.
Вообще ничего не знаю про поддержку SQL в лазаре - может она не потокобезопасная и тогда все общение с SQL должно происходить в главном потоке, а приложение-сервер должно служить сериализатором для кучи клиентов.

[Sharfik]

между клиентом и сервером, с сервером БД нормально все пока.

[Shleps]

тогда только tcpdump/wireshark поможет - смотреть почему разрывается сессия. Изза таймаута или где-то по ошибке разрыв инициируется. ну или кусочек кода потока работы с сокетом в студию.

[Sharfik]

Админ панель допилю и скину. Думаю к выходу Win20 управлюсь.
У меня пока только Windows везде, за одно может кто ни будь попробует скомпилировать под linux.