С сервер клиент: Клиент-серверная архитектура в картинках / Хабр

Максимально эффективная по скорости работы — серверная схема, для клиент-серверной 1С 8.х

Предисловие

Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».

На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти «20% загрузки сетевого интерфейса» = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.

Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.

Итак начнем с главного 1С — построенная на ORM (объектно-реляционном отображении)-система и программист в ней работает не напрямую с реляционным представлением, а с объектами.
ru.wikipedia.org/wiki/ORM

Программист в среде 1С — пишет объектную логику, а за сборку/разборку и запись объектов в «плоский вид» по таблицам базы данных отвечает сама платформа.

Основные «+» и «-» с точки зрения ORM:

«+» Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1

«-» Сложности для создателей «платформ» ORM и проблемы производительности:

Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.

*1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» — это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» — также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» — наиболее оптимально по быстродействию кода и скорости разработки — написать объектный не ряляционно-подобный код.

Глава 1: Расмотрим модель клиент-серверной 1С 8.х

Отмечу основные «узкие» места влияющие на производительность:

1) Первое узкое место — это коммуникационная среда передачи данных.

На рисунке стрелками показаны потоки обмена данными, где «красные» — это Реляционная СУБД<->Объектная СУБ, «оранжевые» — синхронизация между Объектными СУБД.

Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.

Рассмотрим на примере сетевого стандарта Ethernet Gigabit (график зависимости скорости передачи данных… ниже)

на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб):

На графике видно, что при использовании пакетов ДАННЫХ =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. (как правильно заметили в комментария к публикаци: это не пакеты протоколов например уровня TCP, а пакеты ДАННЫХ которые генерируют приложения участвующие в обмене)

…
Из практики: такое разнесение на Два отдельных сервера

MS SQL (сервер №1)< — Ethernet Gigabit —> «Сервер 1С»(сервер №1)
проигрывало по скорости работы платформы

на 50% варианту MS SQL (сервер №1) < — Shared Memory (без сети через участок памяти) —> «Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»

2) Узкое место — это количество отдельных компьютеров «кластеров 1С», чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.

3) Узкое место — количество отдельных процессов сервера 1с, чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» — для обеспечения стабильности. 2*
2* «Уточнение» — для MS Windows существует такое правило:

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

Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.

4)Узкое место – одно-поточность пользовательского сеанса, т.к. каждый отдельно взятый — пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц — будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.

Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты — наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)

1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»

1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.

2) быстрая дисковая система на SSD

3) MS SQL < — Shared memory —> «Сервер 1С»

2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….

Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))

Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».

1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.

2) быстрая дисковая система на SSD

3) MS SQL < — Shared memory —> «Сервер 1С»

Клиент-серверное взаимодействие в реальном времени с помощью веб-сокетов

Перевод статьи Джона Мюллера — What Is a WebSockets Push-Styled API and How Does It Work?

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

Что такое веб-сокет?

Веб-сокеты позволяют клиенту установить такое соединение с сервером, при котором данные будут приходить при возникновении серверного события (event-driven) в режиме реального времени. В отличие от множества веб-технологий, веб-сокеты не следуют стратегии «Запрос-ответ», при которой соединение открывается для выполнения запроса, и закрывается сразу после его выполнения. Веб-сокеты держат соединение открытым. Следовательно, клиенту не требуется постоянно опрашивать (poll) сервер на предмет наличия обновлений, что значительно ускоряет быстродействие приложения при меньшем расходе ресурсов. Веб-сокет состоит из следующих частей:

• Клиент (Client): делает запрос к серверу с целью получения определенных данных.
• Портал веб-сокета (Websocket Gateway): является интерфейсом между клиентом и сервером.
• Сервер (Server): Отсылает обновления клиенту через портал веб-сокета, в режиме реального времени.

Смысл веб-сокета — предоставить альтернативу HTTP-соединению, в виде TCP-соединения. Первоначальный запрос клиента выполняется с помощью HTTP, в котором указывается заголовок для смены (upgrade) протокола, и всё последующее взаимодействие выполняется с помощью протокола веб-сокетов (WS protocol). Другими словами, вместо отправки запроса к http://<чего-нибудь>, происходит отправка к ws://<чего-нибудь>. Данная техника достигает следующих целей:

• Передается только важная информация, без дополнительной нагрузки в виде HTTP-заголовков, что экономит ресурсы и открывает возможность для взаимодействия в реальном времени.
• Создается полноценный дуплекс-канал, при котором отпадает необходимость в таких стратегиях как «опрос» (polling) и «запрос-ответ» (request/response). Как клиент, так и сервер, могут отдавать данные в любой момент. Также, сокращается объем сетевого трафика, что повышает производительность приложения путем сокращения задержки ответа, которая обычно возникает в веб-взаимодействиях.
• Использование единственного TCP-соединения сокращает потребление ресурсов.
• Поддержка открытого TCP-соединения открывает возможность передачи данных в виде потока (streaming).

Также, веб-сокеты превосходят ограничения существующих технологий:

• Опрос (polling): периодически выполняющийся цикл запросов на стороне клиента с целью получить данные от сервера, даже при отсутствии таковой на сервере. Тратится огромное количество ресурсов впустую.
• HTTP потоки (HTTP streaming): несмотря на то что соединение остается открытым всё время, использование стандартных HTTP-заголовков увеличивает размер передаваемых данных и снижает производительность.
• Асинхронный JavaScript и XML (AJAX): полагается на такой объект JavaScript как XmlHttpRequest ради подмены части страницы, если это потребуется в результате обновления данных. Аналогично, HTTP-заголовки повышают размер передаваемых данных, а взаимодействие через полу-дуплекс требует больше TCP каналов, и когда Веб-сервер отправляет данные отдельным клиентам — тратится больше ресурсов.

Для использования веб-сокетов требуются совместимые браузеры, в список которых входят также: Chrome, Edge, Firefox, Internet Explorer, Opera, и Safari (см. caniuse, прим. переводчика). Потребность в совместимом браузере ограничивает пользу от веб-сокетов (однако, это ограничение незначительно пока нет необходимости в поддержке большого количества пользователей со старыми браузерами).

Хоть и данная статья рассказывает, в основном, о взаимодействии браузера с сервером через веб-сокеты, есть также возможность веб-сокетного взаимодействия между серверами; клиенты для веб-сокета доступны для большинства основных серверных платформ: Node.js, PHP, Python, Ruby, .NET, и Java.

Клиент-серверные технологии | BUGZA

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

Типы сервисов:

Изначально предоставляли доступ к гипертекстовым документам по протоколу HTTP (Hyper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности, работу с бинарными файлами (изображения, мультимедиа и т.п.).

• Серверы приложений

Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.

• Серверы баз данных

Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом, СУБД находится на сервере, к которому и подключаются клиентские приложения.

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

• Прокси-сервер

Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и, при этом, обеспечивая защиту сети.

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

• Файрволы (брандмауэры)

Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.

• Почтовые серверы

Предоставляют услуги по отправке и получению электронных почтовых сообщений.

• Серверы удаленного доступа (RAS)

Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.

Для доступа к тем или иным сетевым сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:

«Тонкий» клиент

Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере. Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют «универсальным клиентом».

«Толстый» клиент

Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются, в основном, за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных).

Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

В последнее время все чаще используется еще один термин:«rich»-client. «Rich» -клиент, своего рода, компромисс между «толстым» и «тонким» клиентом. Как и «тонкий» клиент, «rich»-клиент также представляет графический интерфейс, описываемый уже средствами XML и включающий некоторую функциональность толстых клиентов (например, интерфейс drag-and-drop, вкладки, множественные окна, выпадающие меню и т.п.)

Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.

Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:

• XAML (eXtensible Application Markup Language) — разработан Microsoft и используется в приложениях на платформе .NET.
• XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox.
• Flex — мультимедийная технология на основе XML, разработанная Macromedia/Adobe.

Протокол передачи данных — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии ПО.

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

Свой асинхронный tcp-сервер за 15 минут с подробным разбором

Ранее я представил пару небольших постов о потенциальной роли Spring Boot 2 в реактивном программировании. После этого я получил ряд вопросов о том, как работают асинхронные операции в программировании в целом. Сегодня я хочу разобрать, что такое Non-blocking I/O и как применить это знание для создания небольшого tcp–сервера на python, который сможет обрабатывать множество открытых и тяжелых (долгих) соединений в один поток. Знание python не требуется: все будет предельно просто со множеством комментариев. Приглашаю всех желающих!

Мне, как и многим другим разработчикам, очень нравятся эксперименты, поэтому вся последующая статья будет состоять как раз из серии экспериментов и выводов, которые они несут. Предполагается, что вы недостаточно хорошо знакомы с тематикой, и будете охотно экспериментировать со мной. Исходники примеров можно найти на github.

Начнем с написания очень простого tcp–сервера. Задача сервера будет заключаться в получении и печати данных из сокета и возвращения строки Hello from server!. Примерно так это выглядит:

Синхронный tcp-сервер

import socket

# Задаем адрес сервера
SERVER_ADDRESS = ('localhost', 8686)

# Настраиваем сокет
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(SERVER_ADDRESS)
server_socket.listen(10)
print('server is running, please, press ctrl+c to stop')

# Слушаем запросы
while True:
    connection, address = server_socket.accept()
    print("new connection from {address}".format(address=address))

    data = connection.recv(1024)
    print(str(data))

    connection.send(bytes('Hello from server!', encoding='UTF-8'))

    connection.close()

Здесь все довольно просто. Если вы не знакомы с понятием сокета, то вот очень простая и практическая статья. Мы создаем сокет, ловим входящие соединения и обрабатываем их согласно заданной логике. Здесь стоит обратить внимание на сообщения. При создании нового соединения с клиентом мы пишем об этом в консоль.

Хочу сразу заметить, что не стоит серьезно вникать в листинги программ до полного прочтения статьи. Совершенно нормально, если что-то будет не совсем понятно в самом начале. Просто продолжайте чтение.

Нет особого смысла в сервере без клиента. Поэтому на следующем этапе необходимо написать небольшой клиент для использования сервера:

tcp-клиент

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import socket

MAX_CONNECTIONS = 20
address_to_server = ('localhost', 8686)

clients = [socket.socket(socket.AF_INET, socket.SOCK_STREAM) for i in range(MAX_CONNECTIONS)]
for client in clients:
    client.connect(address_to_server)

for i in range(MAX_CONNECTIONS):
    clients[i].send(bytes("hello from client number " + str(i), encoding='UTF-8'))

for client in clients:
    data = client.recv(1024)
    print(str(data))

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

Давайте запустим сервер. Первое, что мы видим:

server is running, please, press ctrl+c to stop

Это означает, что мы успешно запустили наш сервер и он готов принимать входящие запросы. Запустим клиент и сразу увидим в консоли сервера (у вас порты могут быть другими):

server is running, please, press ctrl+c to stop
new connection from ('127.0.0.1', 39196)
b'hello from client number 0'
new connection from ('127.0.0.1', 39198)
b'hello from client number 1'
...

Что и следовало ожидать. В бесконечном цикле мы получаем новое соединение и сразу же обрабатываем данные из него. В чем тут проблема? Ранее мы использовали опцию server_socket.listen(10) для настройки сервера. Она означает максимальный размер очереди из еще не принятых подключений. Но в этом нет совершенно никакого смысла, ведь мы принимаем по одному соединению. Что предпринять в такой ситуации? На самом деле, существует несколько выходов.

1. Распараллелить с помощью потоков/процессов (для этого можно, например, использовать fork или пул). Подробнее здесь.
2. Обрабатывать запросы не по мере их подключения к серверу, а по мере наполнения этих соединений нужным количеством данных. Проще говоря, мы можем открыть сразу максимальное количество ресурсов и читать из них столько, сколько сможем (сколько необходимо на это процессорного времени в идеальном случае).

Вторая идея кажется заманчивой. Всего один поток и обработка множества соединений. Давайте посмотрим, как это будет выглядеть. Не стоит пугаться обилия кода. Если что-то сразу не понятно, то это вполне нормально. Можно попробовать запустить у себя и подебажить:Асинхронный сервер

import select
import socket

SERVER_ADDRESS = ('localhost', 8686)

# Говорит о том, сколько дескрипторов единовременно могут быть открыты
MAX_CONNECTIONS = 10

# Откуда и куда записывать информацию
INPUTS = list()
OUTPUTS = list()


def get_non_blocking_server_socket():

    # Создаем сокет, который работает без блокирования основного потока
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.setblocking(0)

    # Биндим сервер на нужный адрес и порт
    server.bind(SERVER_ADDRESS)

    # Установка максимального количество подключений
    server.listen(MAX_CONNECTIONS)

    return server


def handle_readables(readables, server):
    """
    Обработка появления событий на входах
    """
    for resource in readables:

        # Если событие исходит от серверного сокета, то мы получаем новое подключение
        if resource is server:
            connection, client_address = resource.accept()
            connection.setblocking(0)
            INPUTS.append(connection)
            print("new connection from {address}".format(address=client_address))

        # Если событие исходит не от серверного сокета, но сработало прерывание на наполнение входного буффера
        else:
            data = ""
            try:
                data = resource.recv(1024)

            # Если сокет был закрыт на другой стороне
            except ConnectionResetError:
                pass

            if data:

                # Вывод полученных данных на консоль
                print("getting data: {data}".format(data=str(data)))

                # Говорим о том, что мы будем еще и писать в данный сокет
                if resource not in OUTPUTS:
                    OUTPUTS.append(resource)

            # Если данных нет, но событие сработало, то ОС нам отправляет флаг о полном прочтении ресурса и его закрытии
            else:

                # Очищаем данные о ресурсе и закрываем дескриптор
                clear_resource(resource)


def clear_resource(resource):
    """
    Метод очистки ресурсов использования сокета
    """
    if resource in OUTPUTS:
        OUTPUTS.remove(resource)
    if resource in INPUTS:
        INPUTS.remove(resource)
    resource.close()

    print('closing connection ' + str(resource))


def handle_writables(writables):

    # Данное событие возникает когда в буффере на запись освобождается место
    for resource in writables:
        try:
            resource.send(bytes('Hello from server!', encoding='UTF-8'))
        except OSError:
            clear_resource(resource)


if __name__ == '__main__':

    # Создаем серверный сокет без блокирования основного потока в ожидании подключения
    server_socket = get_non_blocking_server_socket()
    INPUTS.append(server_socket)

    print("server is running, please, press ctrl+c to stop")
    try:
        while INPUTS:
            readables, writables, exceptional = select.select(INPUTS, OUTPUTS, INPUTS)
            handle_readables(readables, server_socket)
            handle_writables(writables)
    except KeyboardInterrupt:
        clear_resource(server_socket)
        print("Server stopped! Thank you for using!")

Давайте запустим наш новый сервер и посмотрим на консоль:
Вывод асинхронного сервера

server is running, please, press ctrl+c to stop
new connection from ('127.0.0.1', 56608)
new connection from ('127.0.0.1', 56610)
new connection from ('127.0.0.1', 56612)
new connection from ('127.0.0.1', 56614)
new connection from ('127.0.0.1', 56616)
new connection from ('127.0.0.1', 56618)
new connection from ('127.0.0.1', 56620)
new connection from ('127.0.0.1', 56622)
new connection from ('127.0.0.1', 56624)
getting data: b'hello from client number 0'
new connection from ('127.0.0.1', 56626)
getting data: b'hello from client number 1'
getting data: b'hello from client number 2'

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

Как это работает?

Дело в том, что все наши операции с ресурсами (а обращение к сокету относится к этой категории) происходят через системные вызовы операционной системы. Если говорить коротко, то системные вызовы представляют собой обращение к API операционной системы.

Рассмотрим, что происходит в первом случае и во втором.

Синхронный вызов

Давайте разберем рисунок:

Первая стрелка показывает, что наше приложение обращается к операционной системе для получения данных из ресурса. Далее наша программа блокируется до появления нужного события. Минус очевиден: если у нас один поток, то другие пользователи должны ждать обработку текущего.

Асинхронный вызов

Теперь посмотрим на рисунок, который иллюстрирует асинхронный вызов:

Первая стрелка, как и в первом случае, делает запрос к ОС (операционной системе) на получение данных из ресурсов. Но посмотрите, что происходит далее. Мы не ждем данных из ресурса и продолжаем работу. Что же делать нам? Мы отдали распоряжение ОС и не ждем результат сразу. Простейшим ответом будет самостоятельно опрашивать нашу систему на наличие данных. Таким образом, мы сможем утилизировать ресурсы и не блокировать наш поток.

Но самом деле такая система не является практичной. Такое состояние, в котором мы постоянно смотрим на данные и ждем какого-то события, называется активным ожиданием. Минус очевиден: мы впустую тратим процессорное время в случае, когда информация не обновилась. Более правильным решением было бы оставить блокировку, но сделать ее «умной». Наш поток не просто ждет какого-то определенного события. Вместо этого он ожидает любое изменение данных в нашей программе. Именно так и работает функция select в нашем асинхронном сервере:

Теперь можно вернуться к реализации нашего асинхронного сервера и взглянуть на него с новым знанием. Первое, что бросается в глаза, – метод работы. Если в первом случае наша программа выполнялась “сверху вниз”, то во втором случае мы оперируем событиями. Такой подход в разработке ПО называется событийно-ориентированным (event-driven development).

Сразу стоит отметить, что такой подход не является серебряной пулей. У него имеется масса недостатков. Во-первых, такой код сложнее поддерживать и менять. Во-вторых, у нас есть и всегда будут блокирующие вызовы, которые все портят. Например, в программе выше мы воспользовались функцией print. Дело в том, что такая функция тоже обращается к ОС, следовательно, наш поток выполнения блокируется и другие источники данных терпеливо ждут.

Заключение

Выбор подхода напрямую зависит от решаемой нами задачи. Позвольте задаче самой выбрать наиболее продуктивный подход. Например, популярный Javaвеб -сервер Tomcat использует потоки. Не менее популярный сервер Nginx использует асинхронный подход. Создатели популярного веб-сервера gunicorn на python пошли по пути prefork.

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

Что лучше, файловый или клиент-серверный вариант работы 1С?

Работа в программах 1С: Предприятие 8 может быть организована в двух режимах: файловый и клиент-серверный. И в том и в другом варианте все прикладные решения работают полностью идентично.

Какой из этих режимов наиболее предпочтительный для работы в вашей программе 1С:Предприятие 8?

Чтобы ответить на этот вопрос, давайте разберем оба этих режима более подробно…

Файловый вариант работы

Работа в файловом варианте возможна как напрямую непосредственно с файлом базы данных с помощью тонкого клиента или толстого клиента, так и через веб-сервер, если используются клиентские подключения по протоколу HTTP или HTTPS.

Для быстрого и безошибочного функционирования системы необходимо, чтобы все действия (запросы), которые совершает пользователь программы 1С:Предприятие 8, выполнялись на компьютере, который хранит базу данных. Однако в файловом режиме работы 1С:Предприятие 8 механизм реализации запросов иной:

• Блокируется часть файла базы данных для других пользователей системы.
• Заблокированные данные перенаправляются по локальной сети к клиенту.
• Операция изменения выполняется на компьютере пользователя.
• Измененная часть файла возвращается в место хранения.
• Файл базы данных становится доступен остальным пользователям системы 1С:Предприятия 8.

Если в базе одновременно работают более 3-х человек, они генерируют постоянный обмен информации, что значительно тормозит работу всех пользователей. Чтобы ускорить работу и сделать ее стабильной, необходимо некий «диспетчер», который на уровне информационной системы будет координировать и выполнять задачи пользователей. Такой «диспетчер» реализован в клиент-серверном режиме работы.

Клиент-серверный вариант работы

На компьютер-сервер («железо») установлена программа 1С: Сервер, которая позволяет запустить 1С:Предприятие 8 в клиент-серверном режиме. Это значит, что программа 1С, которую запускает пользователь на своем компьютере, работает с программой 1С:Сервер. Та, в свою очередь, работает с базой данных. В качестве инструмента управления базой данных используется СУБД – PostgreSQL, MS SQL и им подобные. При этом клиент-серверная архитектура разделяет всю работающую систему на три различные части, определенным образом взаимодействующие между собой:

• клиентское приложение;
• кластер серверов 1С:Предприятия;
• сервер базы данных.

Программа, работающая у пользователя, (клиентское приложение) взаимодействует с кластером серверов 1С:Предприятия 8, а кластер (1С:Сервер) распределяет запросы адресно к нужному файлу базы данных. Он же определяет очередность выполнения операций и вносит изменения в базу данных.

В этом режиме ресурсоемкие операции выполняются на компьютере-сервере, где размещены файлы базы данных, а не на компьютерах пользователей. Таким образом, для комфортной работы в программе 1С:Предприятие 8 будет достаточно только одной мощной машины. Задача компьютеров пользователей – отражение визуальной оболочки программы, с этим справится практически любой компьютер. Кроме того, физически кластер серверов 1С:Предприятия 8 и сервер баз данных могут располагаться как на одном компьютере, так и на разных. Это позволяет администратору при необходимости распределять нагрузку еще и между серверами, что значительно увеличивает отказоустойчивость информационной системы в целом.

Какие преимущества дает клиент-серверный вариант?

Быстродействие. При работе в клиент-серверном варианте 1С самые объемные и «тяжелые операции», например, групповое перепроведение документов или групповая обработка данных, производятся на серверных мощностях, а конечный результат, так называемая «выборка», предоставляется клиентскому приложению. Увеличить мощность одного сервера (компьютера) проще и дешевле, чем обновить все клиентские машины.
Безопасность. При использовании клиент-серверного режима 1С, пользователям не известно место расположения базы данных. Это эффективный способ пресечь вероятность копирования информации из базы данных. В файловом режиме работы пользователь может легко осуществить кражу данных.
Удобство администрирования. Управление архитектурой информационной системы 1С гораздо удобней и проще осуществлять через Сервер приложений 1С, особенно в вопросах контроля и разграничения правами доступа пользователей к базе данных.
Снижение рисков повреждения базы данных. Использование клиент-серверного варианта обеспечивает большую надежность, так как в нем обеспечивается полная независимость записи данных на сервере от сбоев клиентских компьютеров и локальной сети.

Какой режим работы 1С выбрать – файловый или клиент-серверный?

1. Файловый режим работы в программах 1С подойдет, если:

• небольшая компания с кол-вом одновременно работающих сотрудников с программой 1С не более 3-х.
• с базой данных до 2Гб.

2. Рекомендуем использовать 1С:Сервер (клиент-серверный вариант), если:

• Размер информационной базы от 2 Гб и выше
• Количество пользователей от 3-х и более
• Используете последние версии программ 1С на управляемых формах
• 1С зависает или долго выполняет операции
• В период отчетности зависает и дает сбои
• Планируете увеличение пользователей 1С

Что нужно сделать для перехода на клиент-серверный режим работы?

1. Купить программное обеспечение — лицензия для Сервера 1С:Предприятие.
2. Выбрать СУБД:

3. Настроить СУБД для работы в связке с сервером 1С:Предприятие
4. Установить 1С:Сервер и настроить администрирование.

Остались вопросы? Звоните специалистам IT – компании LIGASOFT, они помогут разобраться.

Тонкий клиент – что это и с чем его едят (на примере WTWare) / Хабр

Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер (Wikipedia ).

Если проще, то тонкий клиент – это недокомьютер, который загружает легкую операционную систему (обычно используется Linux, в обзоре возьмем это за априори) и соединяется с терминальным сервером.

Обычно тонкие клиенты создаются для экономии на железе и ПО, в редких случаях по иным соображениям.

В этой статье я постараюсь сделать краткий обзор WTWare, являющегося Linux дистрибьютивом, разработанным специально для создания тонких клиентов.

Сначала о тонком клиенте.

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

Схема сети с тонкими клиентами выглядит примерно так:

Как это работает:

1. На компьютере с одного из источников загружается тонкий клиент. Основные варианты источников загрузки – LAN, CD, HDD.
2. В процессе загрузки тонкого клиента (или до нее при варианте с LAN) сетевой карте компьютера выдается IP адрес.
3. По окончании загрузки тонкий клиент через rdesktop поднимает терминальную сессию с указанным в настройках терминальным сервером.

Зачем это работает:

1. Существенно снижаются затраты на «железо». Предприятие может купить за копейки старый хлам, и все что нужно для его работы – терминальный сервер с достаточным количеством ресурсов и настроенные тонкие клиенты.
2. Снижаются затраты на программное обеспечение – не нужно покупать ПО на десктопы, достаточно только лицензировать терминальный сервер (но нужно покупать терминальные лицензии).
3. Снижаются затраты на администрирование. Администрировать нужно лишь терминальный сервер. Как показала практика, тонкие клиенты практически не убиваемы (если не прилагать целенаправленные усилия), и практически не дают сбоев. Но нужно понимать, что при смене сисадмина он должен разобраться во всем этом деле, например сэмулировав работу тонких клиентов на виртуальных машинах, ведь любой сбой приведет к общему краху.

Типы загрузок:

1. Загрузка по сети. Работает следующим образом: в локальной сети должны быть подняты DHCP и TFTP серверы. В компьютере должна быть либо сетевая карта с BootROM, либо драйвера для сетевой карты, эмулирующие BootROM. Сетевая карта ищет в сети DHCP сервер, получает все необходимые сетевые настройки + адрес TFTP сервера. Далее происходит обращение к TFTP серверу и загрузка операционной системы.
2. Загрузка с CD/DVD/Flash/IDE — тут стандартно, как и любая другая операционная система.

Что такое WTWare?

WTWare — дистрибутив GNU/Linux, разработанный специально для создания тонких клиентов. За основу взят популярный клиент под названием Thinstation. Основное различие – ориентированность на русских пользователей (в самом Thinstation есть проблемы с кириллицей), плюс всякие мелкие фиксы.

Настройка WTWare.

Я не буду рассказывать про настройку DHCP и TFTP серверов, там все вполне стандартно. Напомню только, что в DHCP сервере нужно указать адрес TFTP сервера, а в TFTP сервере путь до файла загрузки и имя этого самого файла.

Так же я не буду углубляться в тонкую настройку WTWare, т.к. информация на официальном сайте WTWare вполне доступная, ее много и вся она на русском языке. Укажу лишь на основные аспекты.

Итак. В первую очередь качаем образ Thinstation с сайта WTWare. Распаковываем.

Загрузочный файл называется pxelinux.0 при загрузке по протоколу PXE (если BootROM встроен в вашу сетевую или материнскую плату) или wtshell.nbi для загрузчика Etherboot (при использовании эмулятора BootROM).

К слову говоря, Etherboot — оpensource проект, который выпускает прошивки практически для всех существующих сетевых карт. Прошивка Etherboot может быть записана в микросхему BootROM или flash-память сетевой карты, может быть запущена с дискеты или жесткого диска как загрузочный сектор или как программа из DOS.

Далее если вы загружаетесь через LAN и у вас правильно настроены DHCP и TFTP сервера – все должно заработать «как есть». Единственное – не будет найден терминальный сервер, ведь вы еще не конфигурировали ваши тонкие клиенты.

Если вы загружаетесь иным способом, то стоит прочитать тут, выбрав интересующий вас способ загрузки.

Конфигурирование.

Опять таки я не буду углубляться в дебри конфигурационных файлов, потому как там сотни параметров. Тут можно увидеть их полный список. Я расскажу лишь об основных.

WTWare имеет следующие типа конфигурационных файлов:

1. all.wtc – общесистемный конфигурационный файл.
2. list.wtc – подключаемые конфигурационные файлы согласно списка.
3. Индивидуальные конфигурационные файлы.

Индивидуальные конфигурационные файлы могут быть следующих видов:

1. Имя_терминала.wtc. Имя терминала, соотвественно, выдается DHCP сервером.
2. ма.ка.др.ес.те.рм.wtc. Привязка идет по мак адресу подключаемового терминала.

Конфигурационные файлы имеют следующие приоритеты:

1. all.wtc
2. Файлы, указанные в list.wtc
3. Файлы, подключенные через include
4. Индивидуальный конфиг

Конфигурационные переменные общесистемного файла:
win2kIP = 10.100.50.1 // адрес терминального сервера 1.
win2kIP2 = 10.100.50.2 // адрес терминального сервера 2.
video = VESA(S) // универсальный драйвер, работает почти на всех видеокартах
mouse_wheel = on // включить колесо мыши
resolution = 1024×768 // разрешение экрана
bpp = 32 // Глубина цвета

Конфигурационные переменные индивидуальных файлов:

user = username // имя пользователя

password = user_password // пароль пользователя

domain = enterprise_domain // домен предприятия

Если в индивидуальный файл записать переменную, которая присутствует в общем файле — она получит более высокий приоритет.

Так же в индивидуальные файлы прописываются дополнительно подключенные устройства, такие как принтеры, сканера и т.п.

И в конце хотел упомянуть об еще одной интересной возможности – подключение локальных ресурсов (Floppy, DVD, Flash, HDD, Sound). В конфиге выглядит примерно так:

floppy = on

cdrom = on

usb1 = on

sound = on

Диск будет доступен в сессии текущего пользователя из Проводника Windows по адресу: \\tsclient\{floppy|cdrom|usbN}.

Недостатки:

1. Могут возникнуть проблемы с подключением оборудования, если драйвера на него в системе отсутствуют. Знаю, что через некие костыли можно разобрать образ, припихнуть туда драйвера, собрать образ обратно. Сам не пробовал.
2. Если у карточки нет BootROM, могут возникнуть проблемы с подбором Etherboot прошивки (есть не для всех карт).

Лицензирование:

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

Оборудование для создания тонких клиентов:

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

Ну, вот, пожалуй, и все. При правильной настройке терминального, DHCP и TFTP сервера все должно заработать слету. В интернете очень много русскоязычной литературы, поэтому проблем с настройкой быть не должно. Да и вообще в плане документации система мне очень понравилась, на сайте производителя есть почти все.

P.S. Самолично ставил данный продукт на два предприятия, на одном 34 ПК, на втором 16 ПК.

P.P.S. Следует понимать, что данный продукт не является альтернативой тому же Linux, и возможно, имя на каждом ПК по установленной ОС, общая картина будет гораздо приятнее. Возможно и нет. Это именно тонкий клиент, и ничего иного.

ОСНОВЫ КЛИЕНТ-СЕРВЕРНОГО ПРОГРАММИРОВАНИЯ

Отзывы покупателей

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

Ашихмина Ольга Андреевна (31.03.2020 11:28:35)

Курс помог ответить на многие вопросы, с которыми столкнулся в типовых решениях на базе 1С Предприятие.

Черняков Сергей Викторович (14.02.2019 13:40:06)

Отличный курс, все емко и понятно.

Зеленков Евгений Сергеевич (14.02.2019 13:39:42)

Курс полезен не только для начинающих программистов, но для тех, кто имеет опыт программирования в простых формах.

Джем Татьяна Георгиевна (14.02.2019 13:39:26)

Курс полезный. Подача преподавателем информации весьма хорошая.
Арзуманов Роман Германович

Арзуманов Роман Германович (14.02.2019 13:39:09)

Курс актуален и для специалистов и преподавателей колледжей для внедрения в учебный процесс

Пятаева Елена Владеленовна (19.04.2018 12:07:33)

Полезный курс как для начинающих программистов, так и программистов имеющий богатый опыт в работе с 1С в обычном приложении но не имеющих достаточного опыта работы с управляемыми формами

Бибиков Александр Александрович (25.07.2017 17:45:57)

Курс очень понравился. Хороший и знающий преподаватель! Спасибо большое за ваш опыт и знания, которые Вы нам передали

Воробьева Татьяна Сергеевна (04.04.2017 17:20:08)

Курс полезный, познавательный и очень нужный

Ларионов Сергей Васильевич (04.04.2017 17:19:31)

Полезный курс — информация изложена доступна, примеры актуальны — усваивается легко. В книгах информации больше но искать дольше

уркин Николай Викторович (27.02.2017 15:48:11)

Отличный курс с альтернативной точкой зрения на программирование в 1С

Сунгуров Андрей Михайлович (27.02.2017 15:47:44)

Курс сбалансирован, очень полезен! Лектор излагает материал в доступной форме

Турулев Антон Владимирович (17.10.2016 17:51:28)

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

Самрега Юлия Владимировна (17.10.2016 17:50:56)

Данный курс стоит пройти каждому программисту 1С, вне зависимости от опыта

Русаков Федор Владимирович (17.10.2016 17:50:29)

Отличный курс. Много полезной информации. отличный преподаватель

Шевченко Игорь Игоревич (25.07.2016 12:37:09)

Материал представлен глубоко и грамотно. Курсом доволен

Васильев Дмитрий Николаевич (25.07.2016 12:36:15)

Отличный курс, буду рекомендовать другим

Медведев Роман Валентинович (27.04.2016 13:26:12)

Хороший, достаточно подробный курс. Информация курса очень полезна и интересна

Михайленко Анастасия Александровна (30.03.2016 12:15:51)

Хороший курс. Вся информация достаточно подробно и грамотно изложена.
Тема курса полностью раскрыта

Мельник Алексей Романович (30.03.2016 12:11:23)

Очень хороший курс, как все курсы Арутюнова

Денисов Павел Борисович (30.03.2016 12:10:47)

Это не первый курс который я прослушал в УЧ №1, но именно этот курс произвел наиболее положительное впечатление

Литвинцев Александр Владимирович (30.03.2016 12:09:54)

Огромное спасибо преподавателю Арутюнову Сергею! Получил огромный багаж знаний. Все объяснил, все рассказал, по окончании учебного дня не завершал курс на полуслове, а продолжал до полного завершения темы.

Плюйко Олег Анатольевич (25.03.2015 10:24:45)

Большое спасибо преподавателю Арутюнову Сергею. Слушать его курсы — одно удовольствие.

Полищук Анатолий Павлович (31.03.2014 12:22:40)

Полезный курс. Прекрасный преподаватель.

Спасибо!

Еремин Андрей (11.06.2013 15:45:55)

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

Жаль, что автор курса мало публикуется в части обнародования своей концепции предметно-ориентированного программирования на уровне монографий!

Дергачев Станислав Петрович (11.06.2013 15:45:16)

Все освещаемые вопросы очень актуальны. Кроме того, удачно отмечены преимущества нового в новых версиях платформы, тенденции её развития, изоляция уровней и практика программирования.

Петров Владимир Петрович (11.06.2013 15:49:57)

Отлиный курс! Хорошо проработаны сквозные примеры, на которых рассматриваются особенности клиент-серверного программирования.

Магай Василий Анатольевич (11.06.2013 15:49:19)

Хороший курс, позволит перестроится программистам к особенностям клиент-серверной разработки!

Бойко Илья Евгеньевич (09.10.2012 15:45:27)

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

Азаркина Светлана Сергеевна (06.04.2012 12:19:42)

Высокий уровень преподавания. Развернутые ответы на вопросы. Отличный курс!

Иванов Сергей Александрович (11.01.2012 11:11:52)

php — Отправка данных с сервера клиенту?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Отправить пакет с сервера конкретному клиенту с использованием TCP c #

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

linux — Как написать функцию для отключения клиента от сервера на C?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

.

TCP клиент / сервер с сокетами, сервер отправляет файлы клиентам, клиент зависает, Python

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.