Petro123else12то это воспринялось как ошибка
кем воспринялось?
Мною. Моим демоном-драйвером. Воспринялось как ошибка и передалось в сокет А. При этом, если ответ все же придет, но поздно, то его надо проигнорировать.

BlazkowiczЯ бы все входящие сообщения складировал был в очередь. Или даже две очереди. А выделеными потоками (по одному на сокет) разгребал очередь и записывал в сокеты. Проверять время можно по той же очереди.
Тут важна скорость, т.к. "не ответ" в течение какого-то времени должен расцениваться как ошибка - а складирование и потом разгребание - это все же время.

Кстати, а "очередь" в данном контексте это будет что конкретно?

Petro123else12пропущено...

Мною. Моим демоном-драйвером. Воспринялось как ошибка и передалось в сокет А. При этом, если ответ все же придет, но поздно, то его надо проигнорировать.
ТЫ - лишнее звено))))
Не возлагай на себя лишних полномочий))).
Ты - конвертер.
Если конечно, Прибор А сам умеет считать таймАут ответа.
Да я-то с удовольствием все полномочия скину, но у меня ТЗ, а в нем написано, что таймаут ответа как раз я должен считать...

rfqДля начала нарисуйте картинку - как от объекта к объекту у вас движутся сообщения (включая сигналы таймера). Типа таких, которые подсказывает гугл "картинки по запросу data flow" на Data flow diagram . Теперь картинку надо формализировать: везде поставить стрелки, и выписать условие прохождения сообщений через узлы. Типичные условия: узел одновременно обрабатывает не более одного сообщения, узел начинает обработку когда сообщения пришли на все входы, после обработки сообщения удаляются со входов и пересылаются дальше и т.п. Наиболее близкая и понятная математическая модель - сети Петри , но надо избегать ситуаций, когда из одной позиции идут стрелки на несколько переходов - эти ситуации трудно реализуются. Собственно это и будет синхронизация. Останется эту картинку реализовать, но это другой вопрос. Когда покажете картинку, вым сразу подскажут.
Я боюсь, что про сети Петри я помню только то, что я их когда-то, очень давно, изучал, но забыл напрочь, то есть абсолютно... А словесно схему я, вроде как, обрисовал... Или как-то "не очень" обрисовал?

Blazkowiczelse12Тут важна скорость, т.к. "не ответ" в течение какого-то времени должен расцениваться как ошибка - а складирование и потом разгребание - это все же время.

Положить ссылку на объект в коллекцию это просто уйма времени.
Смысл в том, что запись в сокеты вам всё равно надо как-то синхронизировать. И тормозить оно начнет в первую очередь тогда, когда вы начнете куда-попало synchronized пихать.

else12Кстати, а "очередь" в данном контексте это будет что конкретно?
Если нужна скорость, то какую-нибудь реализацию java.util.Queue (см ExecutorService, Executors) - http://docs.oracle.com/javase/tutorial/essential/concurrency/exinter.html
Если нужны транзакционность и сохранение данных, то какое-нибудь легковесное NoSQL хранилище.
Аааа... А то у меня уже начал в мозгу реализовываться сложный механизм очередей... Если это просто коллекции и т.п., то еще ладно...

Blazkowiczelse12Или как-то "не очень" обрисовал?
Ну, так...
Может взять какой-то готовый Proxy и дописать в него нужную логику?
http://grinder.sourceforge.net/g3/tcpproxy.html
Честно говоря, с прокси очень плохо знаком (в смысле программирования). А чем простые сокеты не подходят? Единственное, что не очень понял насчет "блокирующих" - "не блокирующих" сокетов. Если сокет-сервер ждет ответа, то по таймеру его ожидание уже никак нельзя прервать и отправить в его выходной поток информацию?

BlazkowiczTCP прокси это такая программа, которая получает TCP соединение от клиента, затем соединяется с другим TCP сервером. И гоняет туда-сюда данные. Ваша программа это адаптер между каким-то клиентом и каким-то сервером. Т.е. это тот же TCP Proxy, только он данные дополнительно преобразовывает.
Эх, а не сложно ли в нем разбираться? Хотя, можно попробовать - просто я в общих чертах-то представляю сейчас решение задачи на сокетах(в деталях, конечно, хуже представляю), а вот прокси не знаю вообще...

BlazkowiczПод блокировкой здесь понимается Thread, который читает\пишет данные. Блокирующие алгоритмы заставляют потоки ждать, окончания записи, или поступления нового пакета при чтении.
Я чего-то подумал - не усложняю ли я... В принципе я получаю команду из сокета А, обрабатываю, отправляю в Б, получаю ответ, отправляю его в сокет А. В это время может произойти только задержка по времени. Вот в ней у меня загвоздка. И еще загвоздка в посылке сообщения об ошибке из сокета Б в сокет А.

Так-то я просто жду сигнала в А и далее гоняю данные по цепочке. А вот внештатные ситуации... Я не очень понял - как мне здесь помешает поток?

schwaПроблема с блокирующими сокетами еще и в том, что если сервер кроме ответов клиенту может отправлять сам ему какие-то "оповещения", то может возникнуть ситуация, когда клиент, начавший запрос, может получить не ответ на него, а отправленное перед ответом уведомление (хотя это конечно можно конфликт можно разрешить, но придется городить костыли, которые будут это все разрешать). С неблокирующими сокетами такого не будет т.к. вы сами должны будете реализовывать логику отправил запрос/получил ответ.
А я и реализую такую логику. Я не отслеживаю правильность ответа как такового и оповещения посылаю сам (если просрочено время). Вместо ответа на запрос из А в Б, от Б может придти только сообщение об ошибке.

Иногда оно генерируется не как ответ на запрос, а само по себе - вот этот случай для меня пока не понятен. Сервер-сокет А ждет сообщения из сокета, а ему должна придти информация от сокета Б, то есть из режима accept он должен как-то выйти и я ему в выходной поток должен отправить сообщение об ошибке. Как это сделать, я не очень понял...

Petro123else12Как это сделать, я не очень понял...
если там 30 страниц, то просто отправь ему и всё.
Он сам переключается на запись и чтение.
А как это сделать в одном потоке? То есть получается все же нужны два потока - один на обработку сокета А, второй - сокета Б?

Petro123else12А как это сделать в одном потоке?
Execute по таймеру или постоянно

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