Сервер запрашивает информацию у Клиента? - PullRequest
Новая
       12

Сервер запрашивает информацию у Клиента?

0 голосов
/ 12 декабря 2008

В системе клиент-сервер считается ли хорошей архитектурой для серверного метода «запрашивать у клиента» дополнительную информацию? Если так, каков наилучший способ разработать такой сценарий? Есть ли для этого «шаблон»?

Например, предположим, что конечный пользователь выбирает набор записей, которые он хочет удалить, в пользовательском интерфейсе клиента, а затем клиент выполняет «удаление записей» на сервере с набором записей в качестве параметра. Затем сервер находит подмножество тех записей, которые в некотором роде являются «особыми» и поэтому должны быть подтверждены пользователем. Является ли целесообразным, чтобы сервер каким-то образом «перезванивал» клиенту методу «подтверждение записей», продолжая при этом исходный вызов от клиента к серверу?

А как насчет более сложных вызовов на сервере, которые могут потребовать длительного «диалога» между сервером и клиентом?

Ответы [ 4 ]

1 голос
/ 17 декабря 2008

Клиент отправляет список файлов для удаления, верно? Просто позвольте серверу ответить со списком статусов успеха, указав, какой файл был удален, а какой нет, и, возможно, почему он не был удален (не существует, нет разрешения и т. Д.).

Если распространенным случаем является то, что все файлы были успешно удалены, возможно, начните ответ с поля состояния, которое указывает, были ли удалены все файлы, или нужно ли клиенту действительно оценивать коды состояния, чтобы увидеть, как прошла операция. ,

С помощью этого ответа клиент должен иметь возможность обновить свое представление о состоянии сервера, по крайней мере, в отношении файлов, которые были выбраны для удаления (т. Е. Удалить из пользовательского интерфейса те файлы, которые были успешно удалены, но также те, которые больше не существуют, а также, возможно, указывают те файлы, которые сервер не может удалить из-за отсутствия соответствующего разрешения).

1 голос
/ 12 декабря 2008

Какой-то ответ, который говорит: «Записи x, y и z не были удалены, попробуйте еще раз с I_RELLY_WANT_TO установить их удаление», мне показалось бы разумным решением.

Общая картина; не спрашивайте, делайте вещи и сообщайте, пусть клиент решает, что делать дальше. Это можно сделать в контексте постоянного соединения как формы диалога.

Не совсем мое поле, так что ... добавьте 64 мг NaCl

0 голосов
/ 12 декабря 2008

Я думаю, что такая договоренность вполне подойдет. Ничто не мешает серверу ответить клиентом на запрос дополнительной информации и предоставить ее клиенту. Пока сокетное соединение открыто, вы можете свободно отправлять сообщения туда и обратно.

Я видел механизм, когда клиент отправлял сообщение на сервер, и после этого он не делал ничего, кроме небольшого слоя над stdin / out и файловой системой на локальной машине, поскольку сервер контролировал ее. , Это работало нормально и было очень быстро.

0 голосов
/ 12 декабря 2008

Такой обратный вызов меняет роль клиента и сервера. Во многих архитектурах такого типа клиент не может прослушивать запросы. Если это так, вы начинаете смотреть на P2P-систему. Возможно, что-то подобное может сработать. 

client code: 
  special_records = server.deleteRecords(records)
  server.deleteSpecialRecords(special_records)

server code:
  def deleteRecords(records):
    special_records = detectSpecialRecords(records)
    reply(special_records)
    actuallyDeleteRecords(records - special_records)

Таким образом, первый вызов deleteRecords вернул бы список этих специальных записей, которые необходимо явно удалить. Надеюсь, это поможет.

...