Захватывающий и захватывающий фанданго для многопоточности

Question

Приветствия и приветствия,

У меня есть два приложения для Android: одно - сервер, а другое - клиент.Сервер получает строки от двух или более клиентов.Сервер проверяет конфликт входных данных (например, входные данные, полученные в течение 1 мс или чего-либо еще).Как только клиент устанавливает соединение с сервером, сервер создает клиентский объект, который запускает поток while-true, который облегчает прием ввода.

Я полагаю, что с разделением времени процессора в ЦП потоки чередуют свое выполнение.Это проблема, так как мне нужно знать, если два InputStreams отправляют сообщения в течение мс или двух друг от друга.Как я могу допустить это?

public void run() {
  while (true) {
    try {
      if (input.ready()) {
      String s = input.readLine();
          //do stuff, like comparing socket inputs
      }
    } catch (Exception e) {
  }
}

Answer 1

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

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

Если цель состоит в том, чтобы просто узнать, какой клиент отправил данные в первую очередь, то можно просто предположить, что заблокированный input.readline (), который возвращает первым, является тем, который отправил данные первым, учитывая данные одинаковой длины и одинаковую задержку пинга для каждого клиент. Это при нормальных условиях будет правильным. Для работы с данными переменной длины и рядом других проблем, связанных с физической сетью, хорошей настройкой было бы чтение байтов, а не целая строка, что дает вам лучшее представление о том, кто пришел первым, а не какой клиент может отправить всю строку быстрее.