>> По факту TCP может ограничиться рамками UDP, и этого будет достаточно.
> Даже не смешно. Прочитай весь RFC-1180, потом мы сможем разговаривать.
>> Если подытожить, правильно ли я понял, что в моей ситуации проблема заключается
>> в открытии сокета на .2, перед тем как принять следующий (важный
> В твоей ситуации проблема заключается в том, что ты не отличаешь TCP
> от UDP.=))
UDP-а TCP-ой никогда не станет, а вот TCP UDP имитировать может...
Спасибо за критику, и советы.
Ваше мнение о моих проблемах ошибочно, и это подтверждает то, что Вы невнимательно читаете мои ответы, жаль. Искренне надеюсь что у Вас всё гораздо лучше, чем у меня. :) Мне просто показалось, Вы на меня накинулись не по теме вопроса :)
И всё-таки я не буду уподобляться критике в Ваш адрес, глубоко искать какие-то Ваши изъяны и постараюсь Вам вежливо пояснить, то что, возможно, было не очевидно для Вас в моём предыдущем ответе...
Ниже приведен простой пример telnet-сессии. Надеюсь Вы согласитесь что это будет TCP (по крайней мере мой tcpdump показывает так, и судя по Вашим ответам, Вы уж точно разбираетесь где TCP, а где UDP, у меня ведь с этим трудности, не так ли?).
Так вот, в моём случае (об этом я ранее уже писал, Вы просто это проигнорировали), рассматривая приведенный пример, после отправки "HELLO WORLD" ожидать от удалённой стороны успешное подтверждение приема пакета (рамки TCP) - не принципиально, т.к. по факту "HELLO WORLD" уже обработается и сохранится тем, чем мне надо;
В своей терминологии я это (отсутствие подтверждения приёма пакета c "HELLO WORLD") назвал "рамки UDP", жаль что сразу это было не так доходчиво, как я ожидал.(
~$ telnet 10.10.10.2 9999
Trying 10.10.10.2...
Connected to 10.10.10.2.
Escape character is '^]'.
HELLO WORLD
^]
telnet> quit
Connection closed.
В любом случае, огромное спасибо за советы. Ведь куда проще раскритиковать, нежели помочь :)
Горжусь своим собеседником :)
Вариант для распечатки
