как передать инфу js->php->js не через файл?

Voodoo Doll
Voodoo Doll аватар
Offline
Зарегистрирован: 18.09.2016

Привет, all.

Имеем: два клиента - компуктор с js-приложением, и нерутованный (всмысле на котором выполнять bind(), connect() и accept() запрещено операционной системой) телефон. Надо с телефона управлять компом. Посередине схемы (на том же компе) стоит openserver.

Существует ли способ заставить один и тот же php сценарий помнить, что он делал в прошлых своих запусках, не записывая файл? Ибо если телефонов и компов будет 500, то сервер превратится в убийцу винтов.

Voodoo Doll
Voodoo Doll аватар
Offline
Зарегистрирован: 18.09.2016

Как временный костыль знаю RAM disk, но интересно, возможно ли обойтись без него.

UPD, в первом посте ошибка, ессно вместо слова "connect" читать "listen"

UPD2, вроде нашлось. Для интересующихся: https://github.com/google/pywebsocket

BOOM
BOOM аватар
Онлайн
Зарегистрирован: 14.11.2018

Что мешало использовать субд для «памяти о былом»?

sadman41
Онлайн
Зарегистрирован: 19.10.2016

В генерализованном решении без записи в долговременную память не обойтись. В данном конкретном без схемы ничего непонятно - кто что и где должен хранить и как тут замешан дворецк... js-скрипт.  

Был бы там http, я предложил бы ставить куки. Впрочем и JS может при обращении к PHP-скрипту что-то из куки засылать.

 

Logik
Offline
Зарегистрирован: 05.08.2014

Так пишет решено. Из JS через WebSocket на сервер к апаче ходит. А хранить чего современный JS и без кукисов умеет, один SQLite - моща.

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Как будто sqlite - это "не записывая файл". 

Вопрос был в том, как серверную часть избавить от писания на какой-либо носитель. А это - или лупить в mmap или перенести импакт на клиентов. Первое будет терять данные на ребуте, второе - нет. Но, так как от задачи видны только уши, то и совет будет на уровне "а может аспирином полечить?"

Logik
Offline
Зарегистрирован: 05.08.2014

//Вопрос был в том, как серверную часть избавить от писания на какой-либо носитель.

Вы не поняли проблемы. 500 записей в файл на сервере - плохо, 500 записей на 500 разных устройствах, и соответственно в 500 файлов - ОК.

Ну БД и файл - несколько разные сущности и по большому счету куда там СУБД пишет с клиента (может прямо в облако) нам мало дела. Главное не на сервер, по условию задачи. А то что в ИТ данные как правило в файлах - тут Вы правы. Это как бы не обсуждается, по крайней мере если сервер иногда ребутят и потери не допустимы. Факт что JS может сохранять БД на клиенте и имеет нормальный канал на сервер к апаче и следовательно "перенести импакт на клиентов" становится отличным решением.  К примеру так, отправку SQL запроса из пыхи  клиенту к его БД, и возврат выборки в пыху, я думаю ценители оценят ;) И все это асинхронно, без перепаковок в JSON (хотя конечно желающие - могут и JSON юзать) и мегабайт сторонних глюков в библиотеках. Ну а кому то конечно только уши видны.