Вопрос про http сервер и REST
В принципе всё получилось, но сегодня встречался с человеком, который пишет приложения под андроид для нашего проекта, он сказал, что по хорошему нужно использовать не голую передачу байтов через tcp сокеты, а метод REST. Объяснил он преимущество этого метода тем, что в интернетах, в отличие от локалки, соединение часто рвется, и поэтому удобнее не лить потоки байт через сокеты, а порциями передавать в качестве http запросов.я работал с контролером, где использовался именно raw TCP и драйверы для работы с ним были расчитаны на разрыв соединения и т.п.
В принципе всё получилось, но сегодня встречался с человеком, который пишет приложения под андроид для нашего проекта, он сказал, что по хорошему нужно использовать не голую передачу байтов через tcp сокеты, а метод REST.речь о приложении на андроид или об устройствах на микроконтроллере всё таки?
и то и другое
В принципе всё получилось, но сегодня встречался с человеком, который пишет приложения под андроид для нашего проекта, он сказал, что по хорошему нужно использовать не голую передачу байтов через tcp сокеты, а метод REST.ага-ага, пускай найдет хотя бы один gps трекер, который по rest'y льет на сервак данные.
Ваще канеш дело вкуса, если данных много не будет и нагрузка не сильная, то можно и rest.
Если несколько тыщ устройств и данные каждые 10-15 секунд приходят, то лучше "голые байты", а-ля самописные бинарные протоколы.
Нагрузки очень небольшие, в приоритете гибкость и удобство разработки
Ваще канеш дело вкуса, если данных много не будет и нагрузка не сильная, то можно и rest.дело вкуса не бывает, бывает правильный грамотный выбор архитектуры и инструментов. если речь о потоковом видео или передаче огромных массивов инфы - ясен хуй бинар и иже с ними, если речь про редкие простейшие запросы где на оверхед похуй - то HTTP. ты вообще много приложений под мобильные платформы реверсинженирил?
Ну для начала я бы вообще посмотрел в сторону udp, если доставка не критична. Во вторых про часто рвущиеся tcp сессии - это актуально нынче только на беспроводных каналах. Сессии от Москвы до штатов и Германии у меня висят неделями. Без потерь.
не голую передачу байтов через tcp сокеты, а метод RESThttp - это и есть tcp в данном контексте
человек тебе советует не тра#аться самому с надежностью, а заюзать уже написанный код (либу которая умеет реконнекты делать для tcp соединений и быть может предоставляет слой rpc
голая передача байт неудобна тем, что нужно поверх этих байтов организовывать
1) rpc (сюда входит авторизация, маппинг между запросом и ответом на прикладном уровне, обработка как прикладных ошибок, так и сетевых, гарантированная доставка пакетов, если надо)
2) сериализацию прикладных данных
вот что первое гуглится для QT + rpc: http://bitbucket.org/devonit/qjsonrpc/src (не в курсе, что означает "периферийные устройства коннектятся..."; быть может, для них это слишком накладно)
для сериализации данных есть куча либ типа
boost::serialization (тут из C++ кода уже в рантайме как-то генерится протокол)
google protobuf (тут код из протокола генерится, возможны биндинги к другим языкам типа питона и .net)
Вопрос 2 - как лучше всего поднять веб сервер и организовать обработку запросов, приходящих на него?кроме гугла ничего предложить не могу =\
http://stackoverflow.com/questions/4161257/lightweight-http-...
ну в общем всё получилось, http протокол очень простой)
На безопасность, надеюсь, болт не положили?
пока всё крутится в локальной сети, куда у злоумышленника не может оказаться доступа - положили)
Надежды юношей питали....
Да ладно. Пусть будут беззаветными адептами сетевого периметра. нам же лучше.
В принципе всё получилось, но сегодня встречался с человеком, который пишет приложения под андроид для нашего проекта, он сказал, что по хорошему нужно использовать не голую передачу байтов через tcp сокеты, а метод REST. Объяснил он преимущество этого метода тем, что в интернетах, в отличие от локалки, соединение часто рвется, и поэтому удобнее не лить потоки байт через сокеты, а порциями передавать в качестве http запросов.Я дико извиняюсь, но человек плохо понимает, о чем говорит. Тут, в принципе, уже все скептически высказались, я лишь приведу немного других аргументов.
Во-первых, как всем известно, хттп ходит поверх тсп, поэтому любая "порционность" передачи данных, которая есть в хттп, легко делается и в тсп.
Во-вторых, говоря про REST, большинство почему-то имеет в виду HTTP+JSON, когда в определении реста нету ни того ни другого. Да, рест в 99.9% случаях имплементят через них, но это обусловлено исключительно браузерной экосистемой, с джаваскриптом и передачей через хттп. Ничто не мешает иметь рест с бинарным форматом через тсп.
Так как в ембеддеде нету ни браузеров ни джаваскрипта, то это хттп-джейсонство просто бесполезная трата памяти и тактов вашего mcu.
В-третьих, даже в условиях ненадежных нетворков (особенно в условиях ненадежных нетворков) переустановка коннекшена на каждый чих не является оптимальной стратегией, ибо это один лишний раундтрип, который в мобильных сетях может легко занимать секунду, например. Оптимальная стратегия там - коннекшен пулинг с кипэлайвом, который делается зачастую прозрачно для клиентского приложения.
Ничто не мешает иметь рест с бинарным форматом через тсп.А что проще: потратить такты mcu и распарсить пришедшее стандартным методом или геморроиться и придумывать, как именно получать данные из некоего бинарного формата, а потом обучать этому формату новопришедшего сотрудника?
Так как в ембеддеде нету ни браузеров ни джаваскрипта, то это хттп-джейсонство просто бесполезная трата памяти и тактов вашего mcu
В смысле, хоть там и нет джаваскрипта, но уж распарсивать джсон и base64-декодить там можно влегкую, 146%
Слова "бинарный формат" не вызывают у ембеддера страха. Более того, большинству ембеддеров с ним комфортнее. Им не нужно "учиться" каждому "новому формату". Они просто берут, и пишут по описанию формата код, так же как ты по экзамплу джейсона берешь и пишешь свой код.
Единственная здравая мысль у человека с андроидом - слать данные порциями, чтобы при сетевой ошибке не ретрансмиттить все с начала. Но если бы он разбирался в ембеддеде, то он бы знал, что там как правило всю память заретрансмиттить - в пару пакетов влезет.
Единственная здравая мысль у человека с андроидом - слать данные порциями, чтобы при сетевой ошибке не ретрансмиттить все с начала. Но если бы он разбирался в ембеддеде, то он бы знал, что там как правило всю память заретрансмиттить - в пару пакетов влезет.
Слова "бинарный формат" не вызывают у ембеддера страха. Более того, большинству ембеддеров с ним комфортнее. Им не нужно "учиться" каждому "новому формату". Они просто берут, и пишут по описанию формата код, так же как ты по экзамплу джейсона берешь и пишешь свой код.Да я, в общем-то, не спорю, jedem das Seine, просто так универсальнее.
А если брать бинари именно из-за железных ограничений по той же памяти, то это при теперешних технологиях примерно как сейчас в зависимости от задачи задумываться, сколько бит в байте
http://www.wasm.ru/wault/article/show/onebyte
Со времени написания рассказа ембеддед стал пожирнее, конечно, и типичные размеры оперативки сейчас в районе 32кб, но и даже с ними, как ты понимаешь, не разжируешь.
А битов в байте всегда восемь, вне зависимости от задачи.
Со времени написания рассказа ембеддед стал пожирнее, конечно, и типичные размеры оперативки сейчас в районе 32кб, но и даже с ними, как ты понимаешь, не разжируешь.
А битов в байте всегда восемь, вне зависимости от задачи.
А битов в байте всегда восемь, вне зависимости от задачи.Ну мы друг друга поняли, историю ВТ знаем
Кстати, если на серверсайде не хочется писать парсер, то существуют всякие BSON'ы и прочие MessagePack'и.
то существуют всякие BSON'ыА, ну так вот я о нем и не знал. Это как раз то, что я подразумевал под "JSON + base64-decode".
Если бы такого не было, я бы его придумал
В-третьих, даже в условиях ненадежных нетворков (особенно в условиях ненадежных нетворков) переустановка коннекшена на каждый чих не является оптимальной стратегией, ибо это один лишний раундтрип, который в мобильных сетях может легко занимать секунду, например. Оптимальная стратегия там - коннекшен пулинг с кипэлайвом, который делается зачастую прозрачно для клиентского приложения.вайпнул флештулом далвик кеш на стоковой прошивке через рекавери тэвээрпэ?
я честно говоря не понимаю зачем мы что то обсуждаем если мы даже не знаем в чём задача. тут пожалуй сага об XYZ может понадобиться. а то потом окажетс что там надо передавать пару байт в час и делать это можно как угодно
А битов в байте всегда восемь, вне зависимости от задачи.Кстати раз уж подняли эту тему, а основную тему вроде как уже обсудили, то мне тут внезапно стало интересно: бывает таки какое-нибудь специальное железо с количеством бит в байте не равным восьми? Например для сетевого оборудования, где активно работают с 32-битными значениями, или какой-нить специфической железке, которая лопатит числа, помещающиеся в 9 байт, но не 8.
Ну или просто just for fun.
Я понимаю, что разработка чипов не дешевое удовольствие, но мало ли это где-то выгодно?
В основном исторические архитектуры и всякие DSP.
ну про исторические архитектуры я вкурсе. а вот чё за dsp? и как под них программируют? только на асме? потому что под те dsp что я видел писали код на С который по стандарту хочет 8 бит в байте.
В той же джаве вплоть по текущую восьмую версию в чаре 16 бит, но это скоро может поменяться.
А вообще, размер байта не нужно менять, если у тебя большие числа, для этого есть понятие машинного слова и такая штука как векторные инструкции.
А вообще, размер байта не нужно менять, если у тебя большие числа, для этого есть понятие машинного слова и такая штука как векторные инструкции.
в чаре 16 бита какое отношение чары имеют к байтам?
Оставить комментарий
nemec2707
Всем привет, я тут недавно в H&S спрашивал про SCADA-системы, и в итоге не нашел ничего достаточно легковесного для своих целей(опрашивать по сети несколько устройств поэтому решил написать свой велосипед.Сделал приложение на QT, которое является сервером и слушает определенный TCP порт, а периферийные устройства коннектятся к нему, открывая сокеты, и обмениваясь инфой через них.
В принципе всё получилось, но сегодня встречался с человеком, который пишет приложения под андроид для нашего проекта, он сказал, что по хорошему нужно использовать не голую передачу байтов через tcp сокеты, а метод REST. Объяснил он преимущество этого метода тем, что в интернетах, в отличие от локалки, соединение часто рвется, и поэтому удобнее не лить потоки байт через сокеты, а порциями передавать в качестве http запросов.
У меня конечно всё будет в локалке, но хочется сразу делать всё так, чтобы потом можно было вылазить в инет.
Вопрос 1 - мне вообще всё правильно объяснили, и правильно ли я всё понял?
Вопрос 2 - как лучше всего поднять веб сервер и организовать обработку запросов, приходящих на него? Для меня все эти веб-делишки пока темный лес, я умею писать только консольные приложения, несложные гуи, да проги для микроконтроллеров, поэтому буду ацки благодарен за некоторое разжевывание.