Блог

В настоящее время я занимаюсь проектом, в котором я собираюсь создать приложение (созданное на Java) вместе с базой данных. Итак, это будет система клиент-сервер, которую я разрабатываю. Частью моего проекта будет исследование существующих клиент-серверных систем.

Итак, мне было интересно, есть ли какие-нибудь хорошие клиент-серверные системы, созданные с использованием Java, на которые я могу взглянуть? Меня интересуют программы для начинающих и профессиональных программ, но не что-то слишком сложное, с чем я не смогу разобраться.

Я хочу обсудить их в своем исследовании и посмотреть, как они работают.

Спасибо.

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

Блокировка клиент-сервер. Служба блокировки состоит из двух программных компонентов: клиентской библиотеки и сервера. Сервер отвечает за хранение информации о том, кому был предоставлен доступ к какому ресурсу. Библиотека на стороне клиента { которую вы должны реализовать { отвечает за предоставление сервиса клиентам, которым необходимо его использовать. Библиотека должна предоставлять клиентам две функции: int a c q u i r e ( int c l i e n t i d , int r e s i d ); int r e l e a s e ( int c l i e n t i d , int r e s id ); Первая функция позволяет клиенту, идентифицированному с помощью clientid, запрашивать эксклюзивный доступ к ресурсу, идентифицированному с помощью resid, в то время как вторая позволяет клиенту освободить этот эксклюзивный доступ. Вы можете предположить, что как клиенты, так и ресурсы могут быть однозначно идентифицированы по некоторому числовому идентификатору. Кроме того, вызов acquire должен возвращать: 2, если сервер в данный момент недоступен, 1, если клиент вызывает acquire для ресурса, который уже был приобретен другим клиентом; или 0, если сервер запущен, и доступ к ресурсу был предоставлен (или уже предоставлен этому клиенту).

Вызов release имеет аналогичные возвращаемые значения: 2, если сервер в данный момент недоступен; 1, если клиент вызывает release для ресурса, для которого он никогда не вызывал acquire ; или 0, если сервер запущен, и операция выпуска прошла успешно.

Реплицированный сервер. Чтобы обеспечить высокую доступность, вы должны сделать свой сервер избыточным. Вы должны сделать это, преобразовав свой server» в набор процессов {один мастер плюс n реплик. Реплики должны быть синхронизированы с ведущим с помощью надежного протокола многоадресной рассылки.

Клиенты подключаются только к ведущему, выполняя операции получения / выпуска непосредственно к нему. Всякий раз, когда новый запрос поступает на мастер, мастер должен многоадресно передавать этот запрос всем репликам. При получении таких многоадресных запросов от ведущего, реплики должны обновить свое внутреннее состояние, чтобы отразить их. Основной смысл синхронизации реплик заключается в том, что в случае сбоя главного сервера система может продолжить работу, если одна из реплик займет ее место. Чтобы обеспечить правильную работу, ваш надежный протокол многоадресной рассылки должен гарантировать, что даже при наличии сбоев: 1. либо все правильные реплики доставляют сообщение, либо ни одна не доставляет, и; 2. единственный случай, в котором допускается случай «или нет», — это когда мастер завершает работу до любого правильногореплика может доставить сообщение.

Обратите внимание, что нас не волнуют аварийные реплики: они могут доставлять или нет сообщение. Чтобы выполнить эту задачу, мы предлагаем вам адаптировать протокол двухфазной фиксации (2PC), но имея в виду следующее: в отличие от regular» 2PC, аварийные реплики не приводят к тому, что сообщение не доставляется, и единственный случай, о котором вам нужно беспокоиться, — это сбой координатора. Отказоустойчивость. Когда мастер выходит из строя, новый мастер должен вступить во владение. Вы должны предоставить механизм для установки нового мастера (например, реплика может принимать специальное сообщение «стать мастером», которое может быть выдано клиентом при сбое текущего мастера). Кроме того, клиенты должны каким-то образом иметь возможность связаться с новым мастером, как только он будет установлен. Чтобы упростить задачу, допустимо запрашивать все реплики при каждом запросе, чтобы определить, какая из них является главной. 1 Предположения сервера. При реализации сервера вы должны сделать следующие предположения. 1. Набор реплик фиксирован, и реплики могут аварийно завершать работу, но реплики никогда не восстанавливаются; 2. количество ресурсов, которые могут быть получены и освобождены, фиксировано и известно заранее; 3. базовая сеть ненадежна и не гарантирует FIFO (если вы используете UDP, вы должны учитыватьдля этого).

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

1. предполагается, что клиентская библиотека должна правильно выполнять переход на другой ресурс после выбора нового мастера; т. Е. Он должен быть в состоянии каким-то образом найти текущего мастера.