[ненависть][программизды] игнорирование ошибок

> если сети немая, никто ничего не гарантирует на самом деле.

Ну вот и ответ на вопрос ТС'а, о чём тут ещё трепаться-то

> Лучше бы они все ставили error_reporting и/или display_errors в 0...

чем лучше то, позвольте поинтересоваться?

>вообще пожизненный молчок

_молча_.

_молчит_,

Поздравляю, вы изобрели шindoшs.

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

сокет в этом случае как я помню возрвращает ошибку

плохо помнишь, прочитай тред.

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

а что, молчание в тряпочку - это Ъ по вашему?

Мало что изменится от этого.

Наоборот, это принципиальная проблема tcp и источник ошибок в коде.

> Ошибка «нет места» должна детектироваться во время write(), а не close().

write не обязательно детектирует ошибку

close нужно проверять, но это хрен кто делает (я например всегда пишу «временные» скрипты в которых никогда не обрабатываю клоз. правда ни разу от этого не страдал пока, но это специфика веб-разработки. к десктопам таки нужно другое отношение, имхо).

Да что вы привязались к TCP? Какая разница, что там произошло на L4. Вам же нужно знать, не доставили ли пакет, а обработали, или нет.

И в чем заключается принципиальная проблема?

> программа засунула свои байты в сокет и пока ACK не придёт — она из send не выйдет

по таймауту выйдет, емнип.

Это вообще не проблема TCP. Подтверждать доставку должна принимающая сторона посылкой соответствующего уведомления по протоколу IM-а. Пока подтверждение не получено, сообщения считается не доставленным.

name_no перекладывает с больной головы на здоровую, по сути, обвиняя ядро в отсутствии драйверов для астрала.

> write не обязательно детектирует ошибку

А должна бы. На момент записи место, требуемое файлу, известно.

> И, самое интересное — что делать проге, когда она наконец получи от send'а ошибку? Писать, что интернет отвалился?

да, писать. что то типа «сообщение не доставлено» прямо в окне чата и сообщение делать сереньким. я так думаю.

Так вот же он, пока она ждала завершения своего send'а — базовая станция снова появилась.

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

>а что, молчание в тряпочку - это Ъ по вашему?

Нет, конечно, сам ненавижу это. Но ещё больше ненавижу сообщения об ошибках в венде, которые бывают 2-х видов:

— «Инструкция по адресу «4048D1FF» обратилась к памяти по адресу «00000000». Память не может быть «read»». — очень говорящее сообщение об ошибке, особенно если непонятно, какой функции принадлежит адрес, да и исходников нет.

— «STOP 0x0000000A». — no comments.

Только в Линуксе я увидел наконец-то нормальные сообщения об ошибках, но, оказывается, и здесь есть исключения.

А оказывается, что сеть уде минут 10 как отвалилась и ты пишешь в пустоту...

ты знаешь способ определить что сеть отвалилась?!

Вообще, тред — наглядное подтверждение тому, какая херня случается, если игнорировать принципы философии юникса, которые отнюдь не от балды придуманы.

В данном конкретном случае игнорируется этот принцип: «Rule of Repair: When you must fail, fail noisily and as soon as possible.»

> ты знаешь способ определить что сеть отвалилась?!

Я знаю способ определить, что сеть _не_ отвалилась.

ну наверное это селектом делается.. узнаётся ошибка.. я не помню досканально ибо лет 5 уже не брал в руки сокеты и прочие радости сишников, php-шник я нынче.

Поделись

ну ваши примеры - без комментариев, меня они, слава Богу, уже несколько лет как не касаются.
кстати, насчет «память не может быть...» - в линуксе обычно такое происходит тихим вылетом, с записью Segmentation fault в консоль (меня это устраивает, а на хомяков в линуксе мне плевать). Мне не сложно посмотреть выхлоп, но бывают моменты, когда это абсурдно.

гм? ну ведь обработали значит сунули в буфер ядра, не? хотя может Вы и правы, не знаю.

Не

http://www.linux.org.ru/jump-message.jsp?msgid=6543722&cid=6544327

да. heartbeat. XMPP, кстати определяет его.

И в чем заключается принципиальная проблема?

для надёжной доставки нужно городить явные подтверждения на уровне приложения.

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

вот из мана

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)

>ты знаешь способ определить что сеть отвалилась?!

Например, проверять соединение с сервером перед отправкой. Даже сраный QIP умеет и орет, если коннекта с сетью нет.

ну наверное это селектом делается

Ты так и не прочитал топик.

лет 5 уже не брал в руки сокеты

гнилая отмазка.

heartbeat

лолшто?

ты знаешь способ определить что сеть отвалилась?!

Знаю. Если сервер не отвечает на запросы то или сети нет или сервер подох.

наверное мы с ТСом живем в разных реальностях, но у меня большинство программ (если не вообще все) подтверждают получение

что не так?

Э... Лолшто? Это проблема? Это же фича. OSI, все дела )))

Хинт: что будет, если тред-обработчик сервер приложения на другой стороне внезапно закрешилось после приёма последнего буфера?

>наверное мы с ТСом живем в разных реальностях

ну у тебя же Мак Лев? ;)

> и даже более того, close может не детектировать ошибку. нужно делать фсинк перед клоз, чтобы гарантированно детектировать ошибку если закончилось место. это из-за кеша происходит.

Одно дело, когда нам отрубили питание, и мы не дописали данные из кэша, и другое — когда write() «успешно» отрабатывает, не резервируя места под запись данных. Отсутствие места — вполне себе штатная ситуация, с которой адекватно должно работать как ядро, так и приложение.

> Например, проверять соединение с сервером перед отправкой.

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

у меня все операционки одновременно) и линуксов несколько штук

Ну мб. Хотя все равно напрягает писать в пустоту.

А болгенос стоит?

Слишком суровый и неточный способ проверять есть ли «сеть» :З С тем же успехом можно пользоваться обычным SO_KEEPALIVE

> Если сервер не отвечает на запросы то или сети нет или сервер подох.

а если сервер отвечает на запросы с задержкой в 5 минут из-за перегрузки?

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

Но ведь взвоют люди. Когда не видно, сколько минут осталось, просто думаешь «ну когда-ниубдь то и дойдет». А когда написаны цыферки, ты точно знаешь не только что говно, но и сколько граммов.

А болгенос стоит?

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

Это же фича. OSI, все дела )))

OSI никогда не был жив, это даже цисковские инженеры говорят. В реальной жизне всё всегда сложнее.

Хинт: что будет, если тред-обработчик сервер приложения на другой стороне внезапно закрешилось после приёма последнего буфера?

Это баг приложения. Но я согласен, всех проблем так не решить.

Тут мы плавно подходим к тому что tcp говно по определению и настоящий универсальный IPC должен быть пакетный и поддерживать передачу мета-информации(типа пакет принят/пакет обработан/этц). Потому что в том или ином виде это приходится городить в большинстве приложений.

а если сервер отвечает на запросы с задержкой в 5 минут из-за перегрузки?

«а разве это жизнь?». С таким QoS я бы не стал пользоваться сервисом.

>ну ваши примеры - без комментариев, меня они, слава Богу, уже несколько лет как не касаются.

Меня тоже. В основном из-за редкого пользования вендой (только в виртуалбоксе и по необходимости).

кстати, насчет «память не может быть...» - в линуксе обычно такое происходит тихим вылетом, с записью Segmentation fault в консоль

Зато можно через gdb поотлаживать.

А то, что несколько Линуксовых программ молчат при ошибках — проблема только этих немногих программ. В основном же при проблемах доступны подробные логи и нормальные сообщения об ошибках в консольных программах.

NetworkManager, кстати, тоже невнятные ошибки выдаёт. Например, при неудачном подключении к вай-фаю предлагает ввести пароль. Но зато в syslog пишет более подробно (хотя моей проблемы это и не решило).

> гнилая отмазка.

ну.. другой нету..

Технически нет особых проблем узнать, был ли доставлен пакет, кроме лютого батхерта от костылей. Можно каждый раз выставлять размер буффера под пакет, и смотреть, когда write на следующую пачку будет возвращать -1. Или на основании заполненности буфера делать вывод, какая часть данных была доставлена (ибо буфер очищается по интервалу ацка, а не с бухты барахты). Но это всё не правильно. Потому это не проблема TCP и L4. Приложению надо знать, был ли доставлен пакет приложения - пусть оно и проверяет, по своему протоколу.

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

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

Вот этот факт мне и не нравится.