Если реализовывать приложение(dotnet core) с аутентификацией и авторизацией, что лучше из готового?
Объемы данных небольшие(управление и координация доступа к ресурсам).
Что насчет SignalR(asp.net), там вроде есть все это из коробки?
Может есть готовые opensource-реализации tcp, понимаю как реализовать, но не хочется тратить время.
А может извратится и координировать/управлять посредством СУБД(по сути тоже клиент-сервер)?
Здравствуйте, vaa, Вы писали:
vaa>Если реализовывать приложение(dotnet core) с аутентификацией и авторизацией, что лучше из готового? vaa>Объемы данных небольшие(управление и координация доступа к ресурсам). vaa>Что насчет SignalR(asp.net), там вроде есть все это из коробки? vaa>Может есть готовые opensource-реализации tcp, понимаю как реализовать, но не хочется тратить время. vaa>А может извратится и координировать/управлять посредством СУБД(по сути тоже клиент-сервер)?
Судя по вопросам: WebAPI, который из коробки и заточен под реализацию REST API.
На клиенте опять же из коробки HttpClient, ну или RestClient какой сторонний взять для удобства дёргания HTTP-запросов.
Можно и СУБД наружу выставить, если какой-нибудь T-SQL лучше знаком, чем C#
Если серьезно, опиши задачу. Может тебе и правда какой-нить пайп подойдет. А может просто нужно веб-сервер сделать. Между этими решениями много чего есть. Меседжинг, RPC...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Что за приложение? НС>Чего блин?
клиент подключился, авторизовался. посылает на сервер сообщения и получает.
частный протокол для приложения с ограниченным набором типов сообщений поверх tcp.
tcp нужен чтобы были минимальные задержки и в случае дисконнекта можно было сразу среагировать.
задача довольно общая, но готовых решений что-то не гуглится.
signalR в этом смысле наиболее близок в реализации, но там json(не критичино) и странный немного механизм обмена сообщениями.
Если нет ничего лучше под корку, наверно буду юзать его. тем более клиентом может быть тогда и браузер и старый дотнет.
Здравствуйте, karbofos42, Вы писали:
K>Судя по вопросам: WebAPI, который из коробки и заточен под реализацию REST API. K>На клиенте опять же из коробки HttpClient, ну или RestClient какой сторонний взять для удобства дёргания HTTP-запросов. K>Можно и СУБД наружу выставить, если какой-нибудь T-SQL лучше знаком, чем C#
Подумал, нет, важно чтобы соединение было постоянным (задача в пределах локальной сети), чтобы не было задержек связанных с опросом состояния клиентов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
НС>>>Что за приложение? НС>>>Чего блин? vaa>>клиент подключился, авторизовался. посылает на сервер сообщения и получает.
НС>Какой клиент, какой сервер, что за сообщения?
Вроде писал уже клиент-сервер поверх tcp, сообщения типизированные от базового класса. НС>Зачем понадобился свой велосипед?
Почему велосипед? НС>Минимальные это какие и зачем? Что значит "сразу"?
если использовать предложенный Rest(Web)API клиенту самому придется регулярно поддерживать связь с сервером, сообщая что он жив.
аналогично если серверу потребуется дернуть клиента он этого не сможет, опять клиент должен мониторить сервер все время.
НС>Странный чем? Тем что это push?
субъективно, в сравнении с реализацией на TcpListener.
например:
Здравствуйте, vaa, Вы писали:
НС>>Какой клиент, какой сервер, что за сообщения? vaa>Вроде писал уже клиент-сервер поверх tcp, сообщения типизированные от базового класса.
Это не задача, это твое решение.
НС>>Зачем понадобился свой велосипед? vaa>Почему велосипед?
Потому что собственный протокол это велосипедистый велосипед.
НС>>Минимальные это какие и зачем? Что значит "сразу"? vaa>если использовать предложенный Rest(Web)API клиенту самому придется регулярно поддерживать связь с сервером, сообщая что он жив.
Зачем вообще клиенту сообщать серверу что он жив? Какая задача этим решается?
vaa>аналогично если серверу потребуется дернуть клиента
Зачем серверу дергать клиента?
НС>>Странный чем? Тем что это push? vaa>субъективно, в сравнении с реализацией на TcpListener. vaa>например: vaa>
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
НС>>>Зачем серверу дергать клиента? vaa>>например, сообщить что список онлайн-клиентов изменился.
НС>А зачем ему список онлайн клиентов?
заблочить, например, на форме.
vaa>>Что такое невелосипед?
НС>Существующий протокол.
какие поверх tcp есть реализации, кроме SingalR(аналоги)?
Здравствуйте, vaa, Вы писали:
НС>>А зачем ему список онлайн клиентов? vaa>заблочить, например, на форме.
Если клиента нужно заблочить, значит он проявлял какую то недавнюю активность. Значит можно просто показать список клиентов, проявлявших активность за определенный интервал времени, а не заниматься реестрами клиентов с никакой масштабируемостью подобных решений.
vaa>>>Что такое невелосипед? НС>>Существующий протокол. vaa>какие поверх tcp есть реализации, кроме SingalR(аналоги)?
Реализации чего? SignalR, кстати, это не протокол, а библиотека. Протоколы он использует вполне стандартные, по умолчанию WebSockets.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, karbofos42, Вы писали:
K>>Судя по вопросам: WebAPI, который из коробки и заточен под реализацию REST API. K>>На клиенте опять же из коробки HttpClient, ну или RestClient какой сторонний взять для удобства дёргания HTTP-запросов. K>>Можно и СУБД наружу выставить, если какой-нибудь T-SQL лучше знаком, чем C#
vaa>Подумал, нет, важно чтобы соединение было постоянным (задача в пределах локальной сети), чтобы не было задержек связанных с опросом состояния клиентов.
Blazor Server? По сути тот же SignalR и клиент в виде веб-странички на каждый чих обращается к серверу.
Здравствуйте, karbofos42, Вы писали:
K>Blazor Server? По сути тот же SignalR и клиент в виде веб-странички на каждый чих обращается к серверу.
Нет, речь идет об организации взаимодействия между настольным приложением и службой. Blazor это ограничение.
Т.е. даже до уровня независимых 2-3 компонентов (клиент, сервер, общие типы), с возможностью расширения типов информационных сообщений.
Signalr в принципе подходит в этом плане, правда для реализации сервера придется использовать asp.net.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
НС>>>А зачем ему список онлайн клиентов? vaa>>заблочить, например, на форме.
НС>Если клиента нужно заблочить, значит он проявлял какую то недавнюю активность. Значит можно просто показать список клиентов, проявлявших активность за определенный интервал времени, а не заниматься реестрами клиентов с никакой масштабируемостью подобных решений.
Вы предлагаете самостоятельно запрашивать периодически у сервера список клиентов?
Просто чтобы узнать их статус?
По-моему оптимально разослать только изменения(когда они произойдут), в случае с tcp точно известно что клиент отключился/подключился.
Вы же вроде бы предлагаете WEB API, как это реализовать там?
НС>Реализации чего? SignalR, кстати, это не протокол, а библиотека. Протоколы он использует вполне стандартные, по умолчанию WebSockets.
Прикладной протокол для конкретной задачи, например чат.
WebSocket — низкий уровень, практически транспортный. SignalR Hub Protocol
Здравствуйте, vaa, Вы писали:
vaa>Вы предлагаете самостоятельно запрашивать периодически у сервера список клиентов?
Кому запрашивать?
Давай так, если ты собираешься всерьез что то реализовать, а не заниматься мозговым онанизмом, то сделай следующие вещи (не для меня, для себя):
1) Опиши, для чего вообще нужна система и почему ее надо создать. Прям в документе, когда ты попытаешься свой сумбур изложить каша в голове будет потихоньку раскладываться по полочкам.
2) Опиши основные сценарии использования
3) На основании этого напиши диздок с хотя бы одной картинкой про system design
4) Тут настало время написать MVP на самых простых технологиях и с максимальным использованием готового кода, с упором на максимально быстрый результат.
5) И вот только если MVP продемонстрировал, что придуманные тобой концепции работают и кому то нужны, и настанет время выбора конкретных технологий для реализации. К этому моменту ты намного больше будешь знать про продукт и то, какие технологии лучше подойдут.
А сейчас ты просто тратишь свое и чужое время сумбурными сообщениями, на которые в принципе невозможно дать хороший ответ.
vaa>По-моему оптимально разослать только изменения(когда они произойдут)
В большинстве случаев нет, не оптимально. Оптимально оно на 3 пользователях может быть. А на 1000 — большой вопрос.
vaa>, в случае с tcp точно известно что клиент отключился/подключился.
Нет. Там точно так же есть таймауты и обрыв соединения у клиента скорее всего отразится на сервере только через десятки секунд.
НС>>Реализации чего? SignalR, кстати, это не протокол, а библиотека. Протоколы он использует вполне стандартные, по умолчанию WebSockets. vaa>Прикладной протокол для конкретной задачи, например чат.
Например чат это пример (прям самый классический) необходимости push технологий. У тебя чат? Ты вообще уверен что тебе нужен пуш? Под уверен понимается что у тебя есть четкий ответ на вопрос "мне нужен пуш потому что ...".
vaa>WebSocket — низкий уровень, практически транспортный.
Ты только что собирался прям поверх tcp что то накручивать. А тут вдруг уже и WebSockets (который поверх tcp и, даже, отчасти http) у тебя слишком низкий уровень. Что то у тебя в голове бурно бродит.
Здравствуйте, vaa, Вы писали:
K>>Blazor Server? По сути тот же SignalR и клиент в виде веб-странички на каждый чих обращается к серверу. vaa>Нет, речь идет об организации взаимодействия между настольным приложением и службой.
Сколько клиентов, где они расположены и как связаны с сервисом, где предполагается хостить сервис, нужна ли high availability и масштабируемость, какие данные, для чего, с какой частотой и в каком объеме нужно передавать, какие ограничения по времени отклика сервиса, нужна ли аутентификация и авторизация?
vaa>Signalr в принципе подходит в этом плане, правда для реализации сервера придется использовать asp.net.
Придется? Это, типа, минус? У тебя цель — написать как можно больше велосипедов?
