Привет, All!

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

Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?

Главный поток Мастер Надзиратель создает потоки Слушателя Гнезда и Змея Хранителя, затем засыпает, чтобы просыпаться по крику Гнома Оповестителя (таймер на период опроса клиентов).

Поток Слушателя Гнезда- открывает Сокет через Listen (КоличествоКлиентов), и, в цикле крутится с BeginAccept.

Потоки Соединялки, возвращаемые по AcceptCallback — получают рабочий сокет и стартуют потоки Сокетных Трансиверов, возвращая экземпляр Трансивера Мастеру Надзирателю, который кладет его себе на стол (List<Трансивер>)

Сокетный Трансивер получает экземпляр рабочего сокета от Соединялки, получает от клиента через сокет его идентификационный номер и начинает пребывать в ожидании команд Мастера Надзирателя(Через manual reset event)

Мастер надзиратель, проснувшить по крику Гнома Оповестителя, перебирает Трансиверы у себя на столе, и они запрашивают у клиента его координаты

После получения координат от клиентов Трансивер уведомляет Мастера-Надзирателя о координатах (через события, то есть из своего потока)
Мастер Надзиратель, получив координаты от Трансивера, кладет их в хвост Змея-Хранителя

Змей Хранитель, когда просыпается, проверяет наличие у себя в хвосте (List<>) несохраненных данных и сохраняет их. После сохранения всех данных засыпает на некоторое время

В случае ошибки передачи данных поток Сокетного трансивера завершается и он сигнализирует Надзирателю о своей смерти
Мастер Надзиратель, получив оповещение о смерти Трансивера, убирает его со стола

Когда Мастер надзиратель получает от Слушателя Гнезда нового Трансивера, он проверяет наличие трансивера с тем же номером на столе. Если такой находится, он его выкидывает и заменяет новым.

Спасибо тем кто осилил)

ЗЫ. Не бейте сильно)

Здравствуйте, Sshur, Вы писали:

S>Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?

Лично меня "сказочные" названия отвлекают и настраивают на шуточный лад, что мешает восприятию основной мысли.

S>Стояла задача создать сервер по приему данных с портативных устройств (GPS трекеров). Каждое устройство устанавливает соединение с сервером и держит его, а сервер должен периодически их опрашивать.
И сколько одновременно устройств может держать сервер ?

Здравствуйте, Dog, Вы писали:

S>>Стояла задача создать сервер по приему данных с портативных устройств (GPS трекеров). Каждое устройство устанавливает соединение с сервером и держит его, а сервер должен периодически их опрашивать.
Dog>И сколько одновременно устройств может держать сервер ?

до 100

Здравствуйте, Sshur, Вы писали:

S>Привет, All!

S>Стояла задача создать сервер по приему данных с портативных устройств (GPS трекеров). Каждое устройство устанавливает соединение с сервером и держит его, а сервер должен периодически их опрашивать.

S>Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?


S>Спасибо тем кто осилил)

S>ЗЫ. Не бейте сильно)

Как то напоминает автоматический перевод тех/статьи какой-то

Здравствуйте, Sshur, Вы писали:

S>Привет, All!

S>Стояла задача создать сервер по приему данных с портативных устройств (GPS трекеров). Каждое устройство устанавливает соединение с сервером и держит его, а сервер должен периодически их опрашивать.

S>Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?
Так запоминается на самом деле хуже, потому что создается "шум" для восприятия.
Гораздо лучше вместо сказочных имен дал бы названия (одно-слова), которые описывают обязанности каждого объекта. Если однозначно имя дать не удается, то с высокой долей вероятности нарушен SRP, а если имя не удается подобрать из-за тривиальности действий, то видимо объект лишний. Еще и практическая польза будет.

Кроме того старайся при описании архитектуры воздерживаться от деталей типа BeginAccept, тредов и ManualResetEvent.


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

Здравствуйте, gandjustas, Вы писали:

G>Кроме того старайся при описании архитектуры воздерживаться от деталей типа BeginAccept, тредов и ManualResetEvent.
Спасибо



G>Далее что касается архитектуры.
G>Выкинь её нафиг. Быстро упрешься в максимальное количество потоков.

Так, а как спящий поток напряжет систему? Какое максимальное количестве потоков (большей частью спящих) выдержит типичный win cервер?



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


Начал изучать

Здравствуйте, Sshur, Вы писали:

G>>Далее что касается архитектуры.
G>>Выкинь её нафиг. Быстро упрешься в максимальное количество потоков.

S>Так, а как спящий поток напряжет систему? Какое максимальное количестве потоков (большей частью спящих) выдержит типичный win cервер?

Каждый поток хавает как минимум 1 мб адресного пространства, поэтому в реальном приложении на 200 потоках приходит маленькая беленькая лисичка.
Кроме того синхронизация потоков — очень дорогая операция.

Здравствуйте, 24, Вы писали:

24>Здравствуйте, Sshur, Вы писали:

S>>Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?

24>Лично меня "сказочные" названия отвлекают и настраивают на шуточный лад, что мешает восприятию основной мысли.

Я когда такое писал — думал о метафоре из ХП, где разрешено предствлять архитектуру в любом виде. Кроме этого, ИМХО яркие образы лучше запоминаются, чем скучные Поток1, Поток2 или "Главный поток" "Клиентский поток" "Поток сохранения данных в БД" итд. Сколько вы уже видели разных Model, View, Controller? Когда таких проектов много — то они путаются друг с другом. Пусть внутри команды в одном проекте Model называется "Трансгалактический пербулятор" (это утрирую ), а в другом "Скрижали мудрости" например, тогда не придется вспоминать каждый раз чем один model отличается от другого Ну и даже в работе должно быть место шалости

Опять же, если использовать короткие имена — на них проще потом ссылаться. Сказать например "Архивариус" быстрее, чем тот же "Поток сохранения данных в БД".

Здравствуйте, gandjustas, Вы писали:


S>>Так, а как спящий поток напряжет систему? Какое максимальное количестве потоков (большей частью спящих) выдержит типичный win cервер?

G>Каждый поток хавает как минимум 1 мб адресного пространства, поэтому в реальном приложении на 200 потоках приходит маленькая беленькая лисичка.
G>Кроме того синхронизация потоков — очень дорогая операция.

Я как-то на число в 1000 допустимых потоков рассчитывал, при том, что по требованиям мой сервер должен держать порядка 100 параллельных клиентов.

The number of threads a process can create is limited by the available virtual memory. By default, every thread has one megabyte of stack space. Therefore, you can create at most 2,028 threads. If you reduce the default stack size, you can create more threads.

Про производительность они тоже пишут конечно, но интересно померять по факту, что будет со 100 потоками:

However, your application will have better performance if you create one thread per processor and build queues of requests for which the application maintains the context information. A thread would process all requests in a queue before processing requests in the next queue.

Здравствуйте, gandjustas, Вы писали:


G>Далее что касается архитектуры.
G>Выкинь её нафиг. Быстро упрешься в максимальное количество потоков.
G>Поизучай Rx, напиши полностью асинхронный сервер, где опрос устройств выглядит как асинхронная коллекция сообщений. В стотыщмиллионов раз упростишь себе жизнь и уменьшишь нагрузку.
если эти устройства будут общаться по gprs, то имеет смысл все-таки делать stateful сервис (по крайней мере в реалиях России).

Здравствуйте, Sshur, Вы писали:

S>Вот чисто для себя родилось такое описание взаимодействия потоков, чтобы запоминалось лучше — немного пошалил с именами потоков Такое описание понятно? Имеет право на жизнь?

Несколько замечаний:

1) Используйте функциональные названия для сущностей. Названия, данные на основе обязанностей, более понятны, как выше заметил gandjustas.

Примеры: Создавальщик, Наблюдатель, Слушатель, Сохраняльщик, Оповещальщики т.п.

2) При описании архитектуры не вдавайтесь в детали реализации — о BeginAccept, Accept Callback на время следует забыть. Всё это относится к сокетам, а не к архитектуре.

3) И, напоследок, действительно забудьте о динамическом создании потоков (в ответ на запросы клиентов). Все необходимые потоки должны создаваться при старте сервера и их количество должно быть таким, чтобы не проседать по производительности. Можно использовать пул сервисных потоков, которым Слушатель передает запрос от клиента на обработку.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>3) И, напоследок, действительно забудьте о динамическом создании потоков (в ответ на запросы клиентов). Все необходимые потоки должны создаваться при старте сервера и их количество должно быть таким, чтобы не проседать по производительности. Можно использовать пул сервисных потоков, которым Слушатель передает запрос от клиента на обработку.


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

Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, Кирилл Лебедев, Вы писали:

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

Я как раз и имел в виду запрос на подключение. Правильно ли я понимаю, что Вы предполагаете работать с каждым соединением (== клиентом) в отдельном потоке?

Здравствуйте, Кирилл Лебедев, Вы писали:


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

КЛ>Я как раз и имел в виду запрос на подключение. Правильно ли я понимаю, что Вы предполагаете работать с каждым соединением (== клиентом) в отдельном потоке?

Да. Хотя, после этого топика может быть сделаю пул потоков

Сказку не осилил.

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

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

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

Здравствуйте, SpaceConscience, Вы писали:

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

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

Другое дело, что при этом можно не оперировать словом поток, а использовать слово "операция" и порядок её выполнения (последовательно или параллельно).

Здравствуйте, Sshur, Вы писали:

S>Спасибо тем кто осилил)

Я токо не понял, когда у них начнётся заруба?

Здравствуйте, gandjustas, Вы писали:

G>Далее что касается архитектуры.
G>Выкинь её нафиг. Быстро упрешься в максимальное количество потоков.
G>Поизучай Rx, напиши полностью асинхронный сервер, где опрос устройств выглядит как асинхронная коллекция сообщений. В стотыщмиллионов раз упростишь себе жизнь и уменьшишь нагрузку.


Посмотрел RX. Пусть у меня есть коллекция объектов и от них идут сообщения

public delegate void QueryRecievedDelegate (QueryRecievedArgs args)

class Client
{
 public event QueryRecievedDelegate OnQueryRecieved;
....
}

Потом где-то в потоке создания Сlient я подписываюсь на OnQueryRecieved:

...
  var o = Observable.FromEvent<QueryRecievedArgs >(client, "OnQueryRecieved");
o.Subscribe(AsyncQueryRecievedCallback);
...

И AsyncQueryRecievedCallback будет вызываться асинхронно? Я все правильно написал? И вообще, нужен ли здесь RX если изначально в классе Client будет асинхронная работа с сокетами и callback так и так позовется асинхронно?

Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Далее что касается архитектуры.
G>>Выкинь её нафиг. Быстро упрешься в максимальное количество потоков.
G>>Поизучай Rx, напиши полностью асинхронный сервер, где опрос устройств выглядит как асинхронная коллекция сообщений. В стотыщмиллионов раз упростишь себе жизнь и уменьшишь нагрузку.


S>Посмотрел RX. Пусть у меня есть коллекция объектов и от них идут сообщения

S>

S>public delegate void QueryRecievedDelegate (QueryRecievedArgs args)

S>class Client
S>{
S> public event QueryRecievedDelegate OnQueryRecieved;
S>....
S>}
S>

S>Потом где-то в потоке создания Сlient я подписываюсь на OnQueryRecieved:

S>

S>...
S>  var o = Observable.FromEvent<QueryRecievedArgs >(client, "OnQueryRecieved");
S>o.Subscribe(AsyncQueryRecievedCallback);
S>...
S>

S>И AsyncQueryRecievedCallback будет вызываться асинхронно? Я все правильно написал? И вообще, нужен ли здесь RX если изначально в классе Client будет асинхронная работа с сокетами и callback так и так позовется асинхронно?

Основное преимущество Rx не в асинхронности (это как раз легко делается), а в том что такие асинхронные потоки можно обрабатывать с помощью комбинаторов и Linq (читай работают замыкания).