Неверно. Вы если чего-то не понимаете или не знаете, сформулируйте Ваши высказывания в виде вопроса. Иначе кто-то может воспринять Ваши заблуждения как истину в первой инстанции. Я выше подал идею насчёт потоков, но Вы не неправильно её имплементировали. Интернет забит дискуссий на тему full-duplex приложений на Java сокетах. См., например, здесь

Всё что я пишу... не может быть истиной в первой инстанции. Тут экспериментальный форум))

Как вызвать sock.send(); пока работает sock.receive();... ? ))
Вызов метода receive () блокирует выполнение программы на неопределенный срок до получения пакета...
IOException: Address already in use: Cannot bind (Адрес уже используется: не удается привязать).

Это для TCP. А UDP работает иначе...

А пока работает так: есть два независимых сокета (условно):
- сокет 1 работает на передачу (в потоке Thread 1).
- сокет 2 работает на приём (в потоке Thread 2).
Т.к. сокеты и потоки независимы, то один другому не мешает))

Правда могут быть проблемы с NAT... т.к. исходящие и входящие порты не совпадают)) а могут и не быть)) Надо проверять...
А вообще надо более подробно изучить работу сокетов в Java.
Как работают сокеты в W5500 я знаю точно и подробно, а как работают сокеты в Java... я представляю пока ещё не до конца...

Короче... нигде вразумительного ответа по сокетам не нашёл... Это надо ковырять библиотеки Java...
Ну ладно))
Тогда будем использовать отдельные сокеты на приём и передачу... в отдельном потоке))
В Java количество сокетов и потоков - не ограничено))
В W5100 - 4 независимых сокета. full-duplex
В W5500 - 8 независимых секетов. full-duplex
Короче... с количеством сокетов у нас проблем нет))

Добавим часики... ))
Java принимает все входящие пакеты... Автоматом всплывают разные окна... К пакетам автоматом добавляется IP, порт, дата и время когда был отправлен / принят пакет (всё берём из компа).

Роман - я боюсь опять понять Вас неправильно. Чего Вы хотите добиться? Использовать один и тот-же Java UDP сокет независимо на приём и передачу?

Да, хочу использовать один и тот-же Java UDP сокет независимо на приём и передачу.

Я не видел полного кода, но полагаю, что у Вас имеется один поток на приём и другой - на передачу. Это правильно. Однако, неясно почему в одном потоке задействован номер порта 80, а в другом 81. Согласен, что если создавать сокеты в потоках, то их нельзя будет назначить на один и тот-же порт. Значит, следует создать один сокет в стартовой программе вне потоков и передать его потокам, например чераз паракетр конструктора потока. Таким образом, управляющая программа содзаст сокет и потоки на приём и передачу, запустит их и потом terminate. А оба потока будут продолжать использовать созданный ей сокет. Я попробовал таким образом, у меня всё работает.

Идея интересная... Осталось придумать как это сделать))

Заменил Windows XP на Windows 7... Всё работает.

Прикол)) Windows 7 не считает контрольные суммы пакетов Ethernet...

протоколы UDP, DHCP, DNS, TCP... Windows 7 не считает контрольные суммы.

-контрольная сумма заголовка протоколов UDP, DHCP, DNS, TCP... 0000.
-контрольная сумма самих протоколов UDP, DHCP, DNS, TCP... False.
При этом всё работает.))
Остаётся только контрольная сумма самого Ethernet пакета (CRC-32), но в этом Windows не участвует. Этим занимается сетевая карта компа.
Мда... я так понял все дружно забили на спецификацию Ethernet)) и в первую очередь сам Microsoft))
Ну и ладно. Тогда и мы можем отключить контрольные суммы в нашем сервере)) Нашему серверу меньше работы.

а пример кода можно ?

Вот пример кода UDP сервера и клиента. Сервер в main() создаёт сокет и placeholder пакета для передачи клиенту и передаёт это потокам приёмника и передатчика. Таким образом, они используют один и тот-же сокет. Приёмный поток по приёму пакета клиента формирует в общей области памяти пакет для передачи передающему потоку. Передающий поток сканирует длину пакета раз в секунду и как только она станет ненулевой, передаЁт пакет обратно клиенту. Приложение клиента однопотоковое. В цикле оно запрашивает пользователя ввести строку для передачи серверу. После передачи переключается на приём ответа от сервера с выдачей номера порта полученного пакета на передающей стороне, из которого следует, что клиент передаёт пакет и получает ответ с того-же порта сервера. Номер рабочего порта сервера для демонстрации выбран фиксированным (=9876).

Да, работает. Вывод: Сокет UDP full-duplex.
Только нужны пляски с бубном)) Делать отдельные классы... конструкторы... потом всё передавать...
Проще делать отдельный сокет на приём и отдельный сокет на передачу.
Остался самый главный вопрос... как это будет работать с NAT...

То, что Вы перечислили не пляски с бубном а стандартный подход в ООП. Как говорится, тяжело только первые 10 лет, потом привыкните. Может скорее.
Насчёт NAT - если приём и передача с разных портов, то можно внести в конфигурацию роутера на какое приложение передавать входящий пакет с определённого порта. Доступ к конфигуратору роутера обычно доступен через веб-интерфейс. Точнее см. инструкцию к роутеру.

))
Насчёт NAT... Как работает мой домашний NAT я знаю)) Ему пофигу порты)) Ему важны только адреса: MAC и IP.
Но у тут есть одна проблемка... неправильная трансляция адресов (во внутренней сети)...

Гораздо интересней как работает NAT разных провайдеров (включая мобильных)...

Такс... на чём мы тут остановились... Продолжаем поднимать домашнюю сеть. Типа домашний сервер))
Первый раз пишу на Java... поэтому пока всё не идеально))

Маршрутизация.
Есть роутер, сервер, комп, другие устройства...
Роутер получает IP от провайдера по DHCP.
Все устройства в доме подключены к роутеру и получает IP от роутера по DHCP.
В роутере можно пробросить порты. Но мы просто включим режим DMZ. Так проще))
Нарисуем схему, всё подключим и протестируем))

Запускаем Java приложение и смотрим как бегают пакеты по нашей сети...

Вариант 1. (подключение из локальной сети LAN).
-телефон получает 192.168.0.101 (по DHCP от роутера).
-телефон 192.168.0.101 отправляет пакет серверу 192.168.0.3.
-сервер смотрит IP отправителя (Source IP Address) и видит IP телефона 192.168.0.101.
-сервер отправляет пакет обратно телефону 192.168.0.101.
Всё работает.

Вариант 2. (подключение из внешней сети WAN).
-телефон получает 1.2.3.4 (по DHCP от провайдера).
-телефон 1.2.3.4 отправляет пакет роутеру 10.0.0.8.
-роутер (NAT) транслирует пакет серверу 192.168.0.3.
-сервер смотрит IP отправителя (Source IP Address) и видит IP телефона 1.2.3.4.
-сервер отправляет пакет обратно роутеру (NAT).
-роутер (NAT) транслирует пакет обратно телефону 1.2.3.4.
Всё работает.

Но тут есть одна проблемка. )) Чтобы всё работало, надо указать телефону где мы находимся: в LAN или WAN сети.
Для этого в Java приложении добавим кнопочку "LAN/WAN".

Зачем это надо ? Это видно из следующей схемы. Что будет если переключить кнопочку в режим WAN и подключиться к домашней сети LAN:

Вариант 3. (подключение из локальной сети LAN в режиме WAN).
-телефон получает 192.168.0.101 (по DHCP от роутера).
-телефон 192.168.0.101 отправляет пакет роутеру 10.0.0.8.
-роутер (NAT) транслирует пакет серверу 192.168.0.3.
-сервер смотрит IP отправителя (Source IP Address) и видит IP роутера 10.0.0.8.
-сервер отправляет пакет обратно... РОУТЕРУ !!! 10.0.0.8. !!!

-роутер (NAT) транслирует пакет серверу 192.168.0.3.
-сервер смотрит IP отправителя (Source IP Address) и видит IP роутера 10.0.0.8.
-сервер отправляет пакет обратно... РОУТЕРУ !!! 10.0.0.8. !!!

-роутер (NAT) транслирует пакет серверу 192.168.0.3.
-сервер смотрит IP отправителя (Source IP Address) и видит IP роутера 10.0.0.8.
-сервер отправляет пакет обратно... РОУТЕРУ !!! 10.0.0.8. !!!

...
Процесс повторяется бесконечно )) На языке сисадминов получаем "кольцо"... )) Класс))

А что делать в такой ситуации ? Вариантов много...

1 - сначала просто добавил блокировку IP в сервере. Если сервер видит 10.0.0.8, то сервер не отвечает.
Не лучшая идея.

2 - добавил IP отправителя (Source IP Address) в сам пакет.
Теперь сервер смотрит не IP отправителя (Source IP Address) в Ethernet пакете, а IP в самом пакете.
Всё работает.

На этом сриншоте видно как телефон (в нашем случае ПК) обменивается пакетами с сервером.

Стандартные UDP пакеты... с контрольной суммой (CRC-16). Ничего особенного))
В пакете вручную прописываем IP телефона 192.168.0.101.
Сервер берёт адрес отправителя (Source IP Address) из пакета.
Сервер возвращает нам свой IP адрес (сервер) и IP нашего телефона 192.168.0.101 (клиент) .
)) Можно использовать наш сервер для определения IP, вместо сайта https://2ip.ru/ ))

А тут мы подключились к серверу в режиме WAN.

Сервер вернул нам IP роутера 10.0.0.8.

Всё это замечательно, но прописывать вручную IP телефона 192.168.0.101 не лучшая идея. Потому что телефон получает 192.168.0.101 (по DHCP от роутера). Да и сама кнопка "LAN/WAN" мне тоже не нравится.

Тогда сделаем по другому)) Идея простая. Java может определить IP телефона, который он получает от роутера. Затем добавить в пакет и отправить серверу. Тогда кнопка "LAN/WAN" не нужна. ))

Всё работает.

P.S. Придумал протокол обхода NAT. (или по-простому "как обмануть роутер"). ))

А вообще пора уже выкинуть все эти NAT-ы... И вообще пора уже переходить на IPv6. Тогда и NAT-ы не нужны))

Продолжаем ломать поднимать домашний сервер))
Ещё в Java есть куча библиотек для работы с разными файлами. Проверим как это всё работает))

Пишем простенькое Java приложение.
Закидываем ярлык на рабочий стол.

Запускаем наше приложение. Всплывает консоль управления.
Java автоматически создаёт текстовый файл на рабочем столе компа (для записи входящих сообщений).
Java определяет IP нашего компа. Java открывает и слушает порт для входящих сообщений.

Прилетают UDP пакеты от сервера.
Автоматически всплывает окно "входящие сообщения"...
Java определяет IP входящего пакета, длину, определяет тип пакета... считает контрольные суммы пакета... и думает что делать дальше: сохранить / ответить / передать дальше и т.д.
Java определяет дату, время, IP, входящего пакета и записывает всё в текстовый файл - "Журнал".

Журнал входящих сообщений можно посмотреть в текстовом редакторе или просто нажать кнопочку в консоле "Журнал".
Видим всю историю входящих / исходящих сообщений.
"Журнал" можно редактировать: сохранить / удалить / передать дальше и т.д. Достаточно нажать нужную кнопочку в консоле))

Короче... получился простенький типа Java сервер, который можно установить на любой комп, телефон с OC и т.д.
Тогда все устройства в доме будут работать в режиме сервера и будут общаться между собой ))

В общем как-то так))

Что-то проект затормозился))

Надо добавить красок ))

С графикой и текстовыми файлами разобрались. Теперь можем нарисовать любой интерфейс.

Ещё Java умеет работать со звуком, фото, видео...
Надо разобраться со звуком. Например добавить звонок... голосовые сообщения... и т.д.

Добавляем в наш "умный дом" звук))
В Java есть встроенный плеер WAV. https://habr.com/ru/post/191422/
Качаем рингтоны MP3 на телефон... Записываем голосовые сообщения... Делаем нарезки в звуковом редакторе...

Разные звуки нажатия кнопок...
На мобильном телефоне вместо звонка будет плеер с рингтоном))

Теперь наш "умный дом" сообщает нам всё что происходит в доме. )) Например при срабатывании датчика в доме прилетает UDP пакет по Ethernet и по громкой связи мы слышим... типа: "Внимание! Утечка! Аварийные клапаны закрыты!"
АААА !!! Говорящий умный дом
))
Правда пока ещё не Алиса, но уже похоже)) https://yandex.ru/alice

P.S. Ещё в Java есть MP3 плеер... им тоже можно управлять удалённо... по интернету))

roman.com Вы конечно можете делать все что хочетса и как хочетса.
Я не кого не в чем не переубеждаю, а просто поделюсь кое какой инфой, если она вам интересна.
Я просто представил обем роботы которую нада вам проделать, чтобы достичь того что на даный момент может мой goodbot на esp32
Если коротко (меряем все что только можна, парсим погоду с openweathermap.org ,аларм телеграм,управление телеграм, mqtt информ+управление,
мега простое общение с некшеном, управление нагрузками чез гугл асистент, время с нета, два роздельных термостата для газового и электро с привязкой к ночному тарифу и коректировкой температуры по дню недели, сева для открытия окна, шаговый двигатель для штор, веб морда, робота блю пупса на пару с ви-фи, нагрузки включаютса и выключаютса 5тью разными сособами, термостат устанавливаетса пока трема)
И самое главное это всего навсего 51 пр памяти, и работает пипец как стабильно, без пайки, програматоров, и особо не умея писать код, на модуле за 3долара.
Если вы планируете написать что то подобное сами, вам надо пару лет, и не одна авра, и для джава есть прокольная штука називаетса (нодеред).
Если надумаете переходить на esp32+fl6.3(поделюсь своим проектом)

Да не много там писать. Меньше чем пару лет)) Всё практически уже готово. Только добавляются новые функции... какие нужны.

нодеред - интересно. https://nodered.org/ Но мне больше нравится писать код , а не рисовать "квадратики". ))

Со вренем перейдём на esp32... Но пока мне больше нравится Ethernet по проводам. Так проще и надёжней... и безопасней. ))
Сейчас в интернете есть куча программ для взлома Wi-Fi... пароли доступа... анализ трафика... и всё что угодно))
https://softcatalog.info/ru/obzor/progr ... loma-wi-fi
https://www.youtube.com/watch?time_cont ... e=emb_logo
...
и т.д.
Сейчас любой студент может взломать Wi-Fi)) Я надёюсь ты это предусмотрел в своём умном доме ?

Погода с нета... время с нета... аларм телеграм... не проблема. Достаточно знать протокол. ))

Гугл асистент... не знаю. Я не доверяю Гуглу и телеграм... )) Я не хочу использовать в своём доме постороннии сайты и сервисы.

Количество нагрузок и датчиков, типы нагрузок и датчиков а так же режимы их работы... в моём доме не ограниченно)) Точнее ограниченно только моей фантазией))

А что у вас дома не будет вай-фая ? И не будет выхода в глобальную сеть?

У меня дома есть и ви-фи и выход в глобальную сеть.

Вопрос в другом. А как ты организовал у себя защиту от взлома ?

Если кратко, то у меня всё просто))
Дом работает на железке W5500. Железка W5500 имеет постоянный выход в глобальную сеть (через роутер или напрямую через провайдера). Железка W5500 не имеет Web-интерфейса... в ней нет пароля... Взломать эту железку невозможно)) Потому что это просто железка.)) А весть трафик шифруется. Поэтому всё надёжно.
Ви-фи у меня на роутере. Роутер можно взломать... например удалённо по ви-фи. Поэтому максимум что может сделать "хакер" это отключить у меня дома ви-фи. Но к управлению дома он доступ не получит, потому что Дом работает на железке W5500 и весть трафик шифруется. При этом выход в глобальную сеть (напрямую через провайдера) останется.
Это кратко.