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

Действительно надежен только HTTP - извините, но это просто смешно

Кстати, у HTTP нет никаких средств повешения надежности, он наследует все недостатки TCP.

@PavelMayorov Суть в том, что ее выбросит только повторная операция, то есть уже после факта неполучения ACK.

Насчет HTTP - надежность уже в том, что при каждом запросе (возможно) новое подключение к серверу, которое уж точно выбросит исключение, если оно не получится. И то, что всегда есть ответ, который непосредственно получает прикладное приложение, а не остается на уровне ОС, как ACK. Да просто посмотрите, сколько TCP-сегментом в одном HTTP-запросе и ответе. Простота кирпичей не делает дом таким же простым. А еще зависит от реализации. Скажем, в Safari на OS X даже докачка файлов есть. А вот примитивный System.Net.WebClient явно не внушает доверия.

В отличие от многих комментаторов моего ответа - я не пишу о том, с чем не работаю и на чем не зарабатываю деньги. Никаких "знаю понаслышке" и "вычитал". Никогда. С UDP я работал, хоть и минимально.

@Rou1997 каким образом? Запрос ушел, ответ не вернулся - это сервер все еще думает, или пакеты потерялись? Чем это отличается от TCP, поверх которого и сделан HTTP? Почему вы думаете, что комментаторы не работали с этими протоколами?

@Rou1997 Никто вам не мешает работать с TCP в режиме "вопрос-ответ". И в таком режиме он дает ровно те же самые гарантии что и HTTP.

@PavelMayorov Дедлайн мешает. Сколько на нем всего реализовать надо - начиная от Content-Length, защиты от ботов (хотя бы в виде magic sequence) При наличии HTTP - использование TCP в таком режиме - это просто "велосипед".

@Rou1997 вы путаете протокол и библиотеки к нему. Это как раз в HTTP надо заголовок Content-Length реализовывать, а протокол TCP его не требует.

@Rou1997 защита от ботов точно должна вестись на транспортном уровне? У всех ли приложений на свете можно вычислить длину сообщения до отправки?

@Rou1997 вообще-то, в TCP вообще нет пакетов на уровне API.

@etki Защита от ботов и куча прочего должны быть ниже уровнем, чем моя система. Я не хочу все это реализовывать (почему - не буду объяснять - если вам не дано понять, то можете думать, что это потому что я ******). Более того, во многих случаях я даже сервер писать не хочу - а использую готовый. Для HTTP это апач (именно так, с маленькой буквы, как мерседес или макароны) и куча чего еще. А для голого TCP?

@PavelMayorov Ну отправляемый буфер byte[] так назовем, какая разница? Важно, что длина фиксированная, а это неудобно.

@Rou1997 не хотите писать сервер - ради бога! Но зачем в таком случае выдавать себя за эксперта?

@PavelMayorov А если я выдаю себя за эксперта в медицине, то мне и человека самому сотворить? Тьфу. Пойду я.

@Rou1997 кстати, готовый сервер nginx умеет проксировать и обрабатывать голый TCP и столь же голый UDP

@Rou1997 протоколы делятся на уровни по функционалу, а не по тому, что именно вам хочется спрятать. Для TCP это обычный сокет ОС.

@etki Деление - условно. Бывает, HTTP тоже называют транспортным. Взять WebSocket. Этот протокол может работать по HTTP, а может по TCP, и как тогда назвать HTTP и TCP относительно WebSocket? Если оба назвать прикладными - формально неверно. Если оба транспортными - тоже неверно. Но второе удобнее и понятнее, поэтому умные люди в данном случае оба протокола назовут транспортными. А глупые выдадут: "WebSocket может использовать HTTP как прикладной (и TCP как транспортный в таком случае), или только TCP" - бред и бардак, зато по книжке все верно.

@Rou1997 нет никакого условного деления до пятого уровня. Разврат и насилие начинается только в том самом волшебном протоколе HTTP, где метаданные (заголовки) кардинально меняют всю работу протокола. Не знаю, кто называет HTTP транспортным, но слова каких-то там людей - явно не аргумент.

@etki Да люди-то эти совсем "не фиговые"! Вот у создателей socket.io: this.transports = ['polling', 'websocket']; Первое - это HTTP, второй - WebSocket, вообще ни тот, ни другой не транспортный. А создатель jQuery вовсе называет "транспортом" тэги image и script, которые еще выше уровнем, чем HTTP. Впрочем, если для вас главное - не выбрать оптим. решение для конкретной задачи, а соблюсти абстрактные традиции - сохранить верность книжке (такое типично для англосаксов - а программирование, увы, к нам от них пришло. а не более гибких германцев или франков) - то и этот аргумент не подействует.

@Rou1997 какие англосаксы, что вы вообще гхм рассказываете?