Уведомления (push уведомления) по HTTP или WebDAV протоколу без использования стороних протоколов средствами HTTP или WebDAV?
Подскажите как можно реализовать без применения сторонних библиотек или протоколов средствами протоколов HTTP (HTTPS) и/или WebDAV систему PUSH уведомлений? Т.е. сервер HTTP (HTTPS) и/или WebDAV уведомляет о том, что на сервере произошли изменения например, или просто "привет мир" в теле PUSH сообщения.
Возможно ли вообще такое?
Если очень кратко то, есть самописный клиент который скачивает файл по WebDAV протоколу, хочется сделать так чтобы если содержимое файла поменялось - сервер дал знать об этом клиенту и клиент начал скачивание файла. Вместо того чтобы скачивать файл и сравнивать изменился ли он или нет через интервал времени.
Да я уже смотрел в эту сторону, но всеже хотел это решить без использования сторонних приложений. Нет ли у HTTP (HTTPS) и WebDAV каких-либо методов открытого соединения которое передает от сервера к клиенту данные или запросы в случае изменения каких-либо условий на сервере? WebDAV насколько я понял только ждет запросов от пользователя и ничего сам не делает.
dronab: что имеется в виду под "сторонними приложения", SignalR в opensource, после прикрепления исходников к проекту он станет его частью на 100% https://github.com/SignalR/SignalR
dronab: Есть ненулевая вероятность, что если подключить WebDAV в качестве сетевого диска можно будет на него повесить FileSystemWatcher и подписаться на события изменения файлов, в некотором смысле это будет тот самый push, но насколько это корректно будет работать и не будет ли жрать трафик в пустую я не знаю. С http в голову приходит только довольно глупое, но возможно работающее решение. Можно создать проект вебслужбы, установить в параметрах службы большой таймаут и создать функцию, которая не возвращает результат до тех пор пока не произойдет изменение в файлах. Со стороны клиента это будет как вызов функции на этой веб-службе с большим таймаутом ожидания в асинхронном потоке, и если результат таки вернется то значит изменения были (в результате можно вернуть список изменившихся файлов). Эти решения хоть и отвечают на вопрос но являются костылями жуткими и пользовать их не советую. Если нет идеологических мотивов не использовать SignalR то нужно использовать SignalR.
Виталий Пухов: Спасибо за дельный совет и интересный вариант решения я его обязательно попробую. Технически можно использовать SignalR, но идеологические мотивы не позволяют его использовать. "Курение" данных протоколов недало результата или я что-то упустил или не понял поэтому решил спросить других. Тот вариант о котором вы написали - его использование чем чревато? Большим кол-вом полуоткрытых соединений в случае подключения некоторого кол-ва ПК? Или нагрузка на сервер?
Виталий Пухов: да, но в тоже время и дугие варианты потребляют память, процессорное время, оперативку - в чем принципиально отличие этого варианта в негативную сторону? За исключением пожалуй чуть больших потребляемых ресурсов чем например если использовать SignalR. Как это может сказаться на безопастности например? Нехочется открыть во внешню сеть огромную дырку - приходи и пользуйся кому не лень))
dronab: так или иначе ресурсы конечно потребляют оба способа, но для задач нужно использовать правильные инструменты. трудно предсказать как много ресурсов потребуется, нужно пробовать.
Простой
