Именно. Как описан в спецификации TCP/IP. Никаких отклонений, никаких ошибок. Кроме этого - все описанные ошибки TCP/IP протокола аккуратно обрабатываются.Готов поклястся на Библии, что там сделано все что возможно в этом плане.

Если в твоем коде ошибок нет и он работает в соответствии с заданной спецификацией, значит все ОК.

А у тебя - нет, не работает и нет никаких ошибок.

Это у тебя не работает.

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

Еще раз повторюсь: ты смешиваешь разные вещи в одну проблему. В твоем примере есть две области: 1) твой софт, который работает на железке у клиента и 2) окружение, т.е. сеть, в которой работает железка, на которой работает твой софт.

Так вот, по твоему описанию, проблема не в софте, а в окружении. И тут есть 2 способа решения возникшей проблемы:

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

2) ты договариваешься с клиентом и наличие ZigBee устройств в сети становится частью спецификации, т.е. изменяются требования к твоему софту в результате чего софт перестает удовлетворять спецификации. После этого можно начинать думать, как обойти проблему. Т.е. надо погружаться в имеющуюся проблему и пытаться решить ее программным способом. Однако, факт в том, что если есть понимание проблемы и понимание того, как эту проблему можно программно решить, значить ее можно и протестировать. И тестирование нужно не для того, чтобы найти ту или иную проблему, а для того, чтобы убедиться, что софт соответствует спецификации.

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

Моя зона ответственности ограничивается спецификацией на софт.

У меня шеф такой же как ты. Считает, что любые проблемы он должен решить сам. Это просто пипец какой-то. Сейчас вот был "баг", программа выкидывает исключение, что мол "нет папки R:\Backup". Смотрю, говорю, сетевой диск не замаплен, поэтому диска R нет, от сюда исключение. Ошибки нет. Все работает так, как должно. Чтобы доказать это, добавляю диск R - все работает. Через полчаса опять приходит шеф и говорит "Ты зашел под своим аккаунтом, а надо было под доменным". Твою мать! Софт работает! Говорю ему, что значит под доменным аккаунтом этого маппинга нет. Он утверждает, что есть. Смотрим - маппинг есть. Смотрим как он это дело запускает. И оказывается, что он запускает это на класторе с SYSTEM правами. Значит, говорю, у SYSTEM'a нет маппинга на R. И знаешь что он мне заявляет? Говорит, что он не хочет подключать админов и выяснять можно ли добавить маппинг диска для SYSTEM.

Т.е. что мы тут видим? Есть рабочий софт и есть окружение, которое блокирует работу софта. Причины, по которой работа заблокирована известна, устранить программно эту причину нельзя. Зато устранить ее могут (и должны) админы. Так какого хера ты не идешь к админам? Пусть они делают свою работу.

Протокол, точнее - известные мне имплементации, является "грязным" - ты можешь, как на клиенте, так и на сервере получать недостоверную информацию.Определить что именно получено - инфа или туфта - можно... почти всегда. Ну то есть за исключением тех случаев когда нельзя. Вот эти нельзя и интересуют.Вот теперь нарисуй мне примитивный тестик - заглушка выдает константную строку в ZigBee-формате.Тест должен определить корректно ли обрабатывается полученное. Тут именно как ты настаиваешь, без отклонений - чисто твой код.

Давай спецификацию и мое время стоит 100Евро/час.