ZerGДа ему надо будет потоки сделать только ещё, очередь запросов от клиентов и очередь ответов клиентам. Потом один поток будет следить за сокетом и добавлять из него информацию в клиентскую очередь запросов. Второй поток будет выполнять на основе этой клиентской очереди запросов операции с датчиками и ответы складывать в клиентскую очередь ответов. А третий поток будет брать ответы из клиентской очереди ответов и отсылать информацию в соответствующие клиентские сокеты. Чтобы это всё написать, нужно понимать не сокеты, а потоки. И вот в этом-то проблема, потому что по потокам надо сначала книжку читать, в которой всё объясняется по шагам на многих-многих страницах.
сокеты тут запределом галактических империй
Полная версия: API для приложений
> Да ему надо будет потоки сделать только ещё, очередь запросов от клиентов и очередь ответов клиентам … А третий поток будет брать ответы из клиентской очереди ответов и отсылать информацию в соответствующие клиентские сокеты.
Да нет. Нужен только один поток на сетевую часть, причём его доже особо синхронизировать не придётся. А вот эти три потока с очередями синхронизации делают реальные дебилы которые способны только читать книжки по потокам с многими-многими страницами
Да нет. Нужен только один поток на сетевую часть, причём его доже особо синхронизировать не придётся. А вот эти три потока с очередями синхронизации делают реальные дебилы которые способны только читать книжки по потокам с многими-многими страницами
RodegastУ программы, в которой нет многопоточности, есть один поток. Поэтому когда ты говоришь про один поток, их там на самом деле два и они общаются между собой. В нормальных языках они ещё параллелятся на процессоры, а в питоне нет, в нём только эмуляция параллельности. Только ты нихрена не читал, как обычно, поэтому теорию эту не знаешь.
Нужен только один поток на сетевую часть
RodegastСколько у него программ одновременно туда будет подключаться? Сколько экземпляров? С чего ты взял, что он будет подключаться туда только одной программкой, только вручную и только один раз в день? Ну с того, что ты сам так делаешь, потому что у тебя ничего не автоматизировано нигде.
Нужен только один поток на сетевую часть, причём его доже особо синхронизировать не придётся.
Я же думаю о сотнях программ, которые подключаются к этому сокету по многу раз в день, каждая посылает свои запросы, ждёт свои ответы и отключается в разное время. И вот это и есть API у Службы, а не какая-то наколеночная фигня, которую ты ему предлагаешь. Да, он, может, не сделает это, потому что это сложно всё без опыта делать и знаний особых, которые за пять секунд не получишь, но это то, что будет работать, причём годами и надёжно.
Rodegastpy.user.next в целом ответил развернуто
> Да ему надо будет потоки сделать только ещё, очередь запросов от клиентов и очередь ответов клиентам … А третий поток будет брать ответы из клиентской очереди ответов и отсылать информацию в соответствующие клиентские сокеты.Да нет. Нужен только один поток на сетевую часть, причём его доже особо синхронизировать не придётся. А вот эти три потока с очередями синхронизации делают реальные дебилы которые способны только читать книжки по потокам с многими-многими страницами
Я неопнимаю зачем для такой простой задачи писать сокеты и трахать себе мозг с потоками
Особенно товарищь упрется когда нужно будет бить сообщения по длине буфера и так далее с двух сторон
Чем тебе Саник не угоди или Рест в целом?
Или ты для работы принтов свою либу print пишешь?
> Я же думаю о сотнях программ, которые подключаются к этому сокету по многу раз в день
Ой! Ты опять таблетки не выпил? Быстрее прими галоперидол, а то будет как в прошлый раз…
Ой! Ты опять таблетки не выпил? Быстрее прими галоперидол, а то будет как в прошлый раз…
> Я неопнимаю зачем для такой простой задачи писать сокеты и трахать себе мозг с потоками
А я не понимаю зачем для такой простой задачи нужен вебсервер, fastapi и всё прочее. Сокеты это легко, потоки тоже, не хочешь потоков сделай асинхронку. Там работы часа на 1,5.
> Особенно товарищь упрется когда нужно будет бить сообщения по длине буфера и так далее с двух сторон
Чяго? Какие ещё буфера? Если ты не в теме, то лучше молчи, а то за дурачка сойдешь
А я не понимаю зачем для такой простой задачи нужен вебсервер, fastapi и всё прочее. Сокеты это легко, потоки тоже, не хочешь потоков сделай асинхронку. Там работы часа на 1,5.
> Особенно товарищь упрется когда нужно будет бить сообщения по длине буфера и так далее с двух сторон
Чяго? Какие ещё буфера? Если ты не в теме, то лучше молчи, а то за дурачка сойдешь
RodegastСокет использует передачу такую, что надо буфер делать. Если сообщение не поместится в буфер, нужно два буфера склеивать. А если в буфере два сообщения поместились, их надо разделять. А если их там поместилось не половинка и не два, а два с половиной? Вот у тебя мозг сломается, точно. То есть нужно их склеивать, расклеивать, сидеть там, анализ вести. Ты вот говоришь JSON передавать там, а внутри-то может быть фигурная скобочка, и какая из них последняя, чтобы два документа разделить в одной сессии? Они бывают вложенные и ещё в строках. Вот он подключился на сокет и сначала говорит, что ему надо этот датчик, а потом говорит, что ему надо вот этот датчик, на сокет это всё приходит просто непрерывно. Поэтому нужно разделить эти сообщения. Так они ещё могут попадать только своими частями в буфер считывания, а не целиком, и нужно ждать следующее заполнение буфера, чтобы это всё склеить в единый поток данных, а потом уже этот поток данных делить по каким-то логическим меткам. Так что, я думаю, ZerG вот про это говорит.
Какие ещё буфера?
RodegastТы бы поаккуратнее на поворотах
Чяго? Какие ещё буфера? Если ты не в теме, то лучше молчи, а то за дурачка сойдешь
А то похоже что не в теме ты сам и сам же кудато сойдешь.
Выше тебе py.user.next детально расписал и это только начало
Добавь сюда еще не одного а несколько клиентов и за полтора часа ты сможешь только план проекта на бумажке нарисовать
И самое главное - автору потом все это нужно выкидвывать в тот же веб
То есть тут не то что шкурка выделки не стоит - тут вобще не стоит
Это равносильно тому что бы писать веб-сайт на С
Сделать можно - но быстрее похапе выучить
Вернемся к нашим баранам
from sanic import Sanic from sanic.response import text app = Sanic("MyHelloWorldApp") @app.get("/dev_1") async def hello_world(request): data = get_data_from_device(1) return text(data) @app.get("/log") async def hello_world(request): data = "SELECT * FROM Logs WHERE XX".fetchall() return text(data)
И все - это наполовину готовый код за 15 секунд без знания питона вобще
а дальше
делаем запрос на http://192.168.0.123/log
И читаем данные.
Опять же - немного магии и на этом же месте можно добавить прстенький веб шаблон и не лезть на штангку вовсе
Хочешь человеческого - добавь 3 строчкии в джисоне пуляй
И все. Иногда нужно просто решать задачу а не выйоживаться уровнем общих знаний
В целом - если тебе проще - пиши на сокетах это или на Aсемблере
Но навязывать не стоит
> Ты бы поаккуратнее на поворотах
> А то похоже что не в теме ты сам и сам же кудато сойдешь.
Тогда ткни меня носом в тот буфер размер которого нужно выставить для организации обмена сообщениями через TCP сокет
> Выше тебе py.user.next детально расписал и это только начало
Он выписал себе детальную справку в том что не знаком с передачей данных через сокеты. Хотя мог бы и не выписывать, это и так понятно.
> И самое главное - автору потом все это нужно выкидвывать в тот же веб
С чего ты это взял?
> А то похоже что не в теме ты сам и сам же кудато сойдешь.
Тогда ткни меня носом в тот буфер размер которого нужно выставить для организации обмена сообщениями через TCP сокет
> Выше тебе py.user.next детально расписал и это только начало
Он выписал себе детальную справку в том что не знаком с передачей данных через сокеты. Хотя мог бы и не выписывать, это и так понятно.
> И самое главное - автору потом все это нужно выкидвывать в тот же веб
С чего ты это взял?
Появилась необходимость сделать интерфейс (API) для взаимодействия с ним из другого приложения (запуск/останов, получение данных). Клиентское приложение может быть на другом компьютере.
В интернете по запросу API информация в основном по RESTAPI (взаимодействие через HTTP). Не хотелось бы ещё и вэбсервер поднимать для этого.
Misha_White
Главное, чтобы программа могла что-то принимать (команды: текст, JSON) и отдавать (текст, JSON).
На самом деле, у меня ещё Джанга есть на другом серваке. Думаю в её базу (или в отдельную через роутер) писать данные, чтобы через Джангу управлять кое-какими функциями, реализованными на стороне БД (менеджер расписаний, например). Да и Rest запросы можно прям из Джанги в приложение отправлять….
RodegastХ__йивознаит - может отсюда?
С чего ты это взял?
Какието магнитный бури по ходу
Или с возрастом мы таки становимся ворчунами