Информация об изменениях

Сообщение Быстрый ID для объектов сетевого протокола от 20.04.2018 15:53

Изменено 20.04.2018 16:05 Barbar1an

Быстрый ID для объектов сетевого протокола
например есть у нас протокол где команда это ObjectcId.Property = Value

мне интересно как можно организовать самый быстрый переход от объекта к его указателю, и на сервере и на клиенте

1. генерировать один GUID, но тогда придется искать каждый айди в таблице на каждую команду

2. тупо обменяться адресами в памяти — сервису сказать где объект лежит на клиенте, и наоборот, тогда можно просто привести айди к указателю что супербыстро, но тут нужен запрос-ответ, а это тормоза
глобальная уникальность будет обеспечиваться уникальностью пары айди процесса(или айпи, или сессии) и адреса в памяти

как компромис — клиент создает объект и шлет его адрес, а сервер помещает его в таблицу, и наоборот

3. выделять доступный один айди как HANDLE в винде, тут доступ быстрый — просто по индексу в массиве, но если объект создается клиентом то нада както обеспечить синхрронизацию с серверйно таблицей, либо опять ждать овтета


мож чтото лучше есть, мне лично нравится идея адреса, тогда не нада на каждую команду лукап делать


4. еще придумал извратный: севрер создает пул объектов заранее и рассылает клиентам пачки доступных адерсов, когда клиент исчерпал пул — он просит новую пачку адресов
это решение зарпос-ответ через предварительную аллокацию
Быстрый ID для объектов сетевого протокола
например есть у нас протокол где команда это ObjectcId.Property = Value

мне интересно как можно организовать самый быстрый переход от объекта к его указателю, и на сервере и на клиенте

1. генерировать один GUID, но тогда придется искать каждый айди в таблице на каждую команду

2. тупо обменяться адресами в памяти — сервису сказать где объект лежит на клиенте, и наоборот, тогда можно просто привести айди к указателю что супербыстро, но тут нужен запрос-ответ, а это тормоза
глобальная уникальность будет обеспечиваться уникальностью пары айди процесса(или айпи, или сессии) и адреса в памяти

как компромис — клиент создает объект и шлет его адрес, а сервер помещает его в таблицу, и наоборот

3. выделять доступный один айди как HANDLE в винде, тут доступ быстрый — просто по индексу в массиве, но если объект создается клиентом то нада както обеспечить синхрронизацию с серверйно таблицей, либо опять ждать овтета


мож чтото лучше есть, мне лично нравится идея адреса, тогда не нада на каждую команду лукап делать


4. еще придумал извратный: севрер создает пул объектов заранее и рассылает клиентам пачки доступных адерсов, когда клиент исчерпал пул — он просит новую пачку адресов
это решение просблемы тормозов зарпос-ответа через предварительную аллокацию сразу кучи объектов
ну и тут у нас будет перерасход памяти на сервере