Сообщение Re[3]: Выбор протокола, для работы с прибором от 27.03.2015 11:28
Изменено 27.03.2015 12:32 AlexGin
Здравствуйте, Nikolay_Ch, Вы писали:
LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов.
Т.е. для работы в среде веб-броузера? Это также интересный вариант. Пока даже не задумывались над этим...
N_C>Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
+100500
Вот я также об этом думал! Ведь тех функций, что в HTTP, мне здесь совсем и не надо!
Исключение — если напрямую (веб-броузером) смотреть "сырые данные" в приборе.
LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов.
Т.е. для работы в среде веб-броузера? Это также интересный вариант. Пока даже не задумывались над этим...
N_C>Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
+100500
Вот я также об этом думал! Ведь тех функций, что в HTTP, мне здесь совсем и не надо!
Исключение — если напрямую (веб-броузером) смотреть "сырые данные" в приборе.
Re[3]: Выбор протокола, для работы с прибором
Здравствуйте, Nikolay_Ch, Вы писали:
LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов.
В том смысле, чтобы приложение АРМ-а работало с прибором (как клиентское приложение) через HTTP?
Есть также вариант — работа в среде веб-броузера. Это также интересный вариант. Пока даже не задумывались над этим...
N_C>Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
+100500
Вот я также об этом думал! Ведь тех функций, что в HTTP, мне здесь совсем и не надо!
P.S. Работа с прибором через веб-броузер не актуальна.
Все данные от прибора, перед визуализацией пользователю, нуждаются в больших доп-расчетах (в т.ч. БПФ),
которые должны выполняться быстро — в скрипте это не сделать.
Посему, считаю реально рассматривать варианты протоколов
a) Низкоуровневые — TCP или UDP;
b) Высокоуровневые — FTP или HTTP.
LS>>на мой взгляд, первое, с чего следует начинать выбор протокола — это поиск реальных причин не использовать HTTP.
N_C>Единственную причину, зачем нужно использовать не менее древний (1997 год, все-таки) и кривой протокол HTTP я вижу только в возможности подключений готовых клиентов.
В том смысле, чтобы приложение АРМ-а работало с прибором (как клиентское приложение) через HTTP?
Есть также вариант — работа в среде веб-броузера. Это также интересный вариант. Пока даже не задумывались над этим...
N_C>Да и то — это только в том случае, если поддержать какой-то протокол поверх HTTP. Потому, как базовый функционал HTTP будет сильно избыточен при необходимости простой передачи файлов а бонуса от этой избыточности никакой не будет.
+100500
Вот я также об этом думал! Ведь тех функций, что в HTTP, мне здесь совсем и не надо!
P.S. Работа с прибором через веб-броузер не актуальна.
Все данные от прибора, перед визуализацией пользователю, нуждаются в больших доп-расчетах (в т.ч. БПФ),
которые должны выполняться быстро — в скрипте это не сделать.
Посему, считаю реально рассматривать варианты протоколов
a) Низкоуровневые — TCP или UDP;
b) Высокоуровневые — FTP или HTTP.