обертки для socket(), connect() и пр.

использовать макросы или нет - дело твое, но
> И отсюда вытекает второй вопрос - насколько подробно нужно обрабатывать errno-коды сетевых функций (как я понимаю, это также одна из причина написания врапперов?).
максимально подробно, от этого зависит качество работы твоего приложения с сетью. сеть постоянно ломается. нужно твердо знать, в каких условиях что делать. и обязщательно вести детальный лог, чтобы админу потом не пришлось добавлять дебаг принты в код самому.

кстати, я врапперы не использую

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

А как наиболее правильно и красиво обрабатывать ошибки? Неужели при каждом вызове делать, например:

fd = socket(...);
switch (fd) {
...
}

IMHO от этого читабельность сильно пострадает. Таки есть смысл все это спрятать во врапперы?

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

>в реальной жизни есть ли смысл применения таких врапперов

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

а вообще можно посмотреть уже готовые библиотеки, к примеру http://ostatic.com/swrapper (их много существует)

> а вообще можно посмотреть уже готовые библиотеки, к примеру http://ostatic.com/swrapper (их много существует)

спасибо за ссылку, посмотрел, но это IMHO совсем упрощенный вариант. Есть ли что-то более серьезное для настоящих мужчин :-) (желательно на ANSI C). Гуглил по socket wrapper library, но вылазят только библиотеки на плюсАх.

>Гуглил по socket wrapper library, но вылазят только библиотеки на плюсАх.

Плюсовая религия - без деструктора никак.

А ты какую задачу решаешь? Если надо тупо что-то переслать то юзай rpc, всякие шины сообщений итп. Кучу времени сэкономишь на разработке и отладке. Ковыряться с сокетами напрямую редко имеет смысл.

>сеть постоянно ломается
если сеть постонно ломается, значит ее нужно чинить.
что за бредовая тенденция считать нормальным явлением ломающуюся сеть?
часом не в провайдере работаете?))

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

зато если такое напишете - можете использовать где угодно.
у меня вот было:
int connect_to_server(char *host, int port); // returns socket
int open_port(int port, int maxcon); // returns socket
этого было почти достаточно (за исключением того, что никак не мог написать приличную обертку для recv)

хоят, ИМХО, подробность нужна только при отладке самих врапперов.
в большинстве случаев - они потом работают исправно.

>> сеть постоянно ломается
> если сеть постоЯнно ломается, значит ее нужно чинить.
дурак ты. по видимому, абсолютно не представляешь себе сеть, кроме как www. что такое udp в курсе? а как работают напрямую поверх ip? все еще так уверен, что сеть - штука надежная?

> что за бредовая тенденция считать нормальным явлением ломающуюся сеть?
это не тенденция, это факт. сеть _не_ работает идеально, из всех ио сеть - самый ненадежный. пакеты постоянно теряются. это нормально, сетевые технологии должны с этим бороться, а программисты - как их применять и разрабатывать.

> часом не в провайдере работаете?))
нет.

> надо предусмотреть обработку наиболее вероятных ошибок (нет сети, файервол заблокировал, домен не найден (ну ошибся человек) и т.д.) и вывод сообщений с минимальным описанием ошибки!
ололо.

> нет сети
это как?

> файервол заблокировал
и как ты это определяешь в своих программах?

> домен не найден
что, целый домен и вот так не найден? плохо искали!

> и вывод сообщений с минимальным описанием ошибки!
ага, и желательно такого типа: "error, exiting"

> А ты какую задачу решаешь? Если надо тупо что-то переслать то юзай > rpc, всякие шины сообщений итп. Кучу времени сэкономишь на разработке и отладке. Ковыряться с сокетами напрямую редко имеет смысл.

Пока конкретную задачу не решаю, читаю Стивенса и вот там мне попались врапперы, которыми я заинтересовался (с какой целью их использует автор и каково их значение в мировой экономике :) ).

А как rpc может помочь при передаче данных? Ведь это больше для выполнения удаленных приложений, как я понимаю. Т.е. в чем бонус использования RPC, а не сокетов напрямую?

И что такое шины сообщений?

Спасибо!

>>> сеть постоянно ломается
>> если сеть постоЯнно ломается, значит ее нужно чинить.
>дурак ты. по видимому, абсолютно не представляешь себе сеть, кроме как www. что такое udp в курсе? а как работают напрямую поверх ip? все еще так уверен, что сеть - штука надежная?
Не дурак. Представляю. В курсе.
но как бы знаешь, писать врапперы, направленные под специфические задачи (да, я считаю udp специфической задачей, за всё время программирования я его так и не попробовал. да, увы!) имхо уже не стоит.
враппер полезен, чтобы не писать одинаковый код в разных программах или ее частях. хоть ты тут тресни, но tcp до сих пор является наиболее распространенным протоколом в сетевых приложениях.

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

> А как rpc может помочь при передаче данных?

так я же не знаю что за ПО ты пишешь, вот и предложил.

Про шины сообщений можно почитать в вводной часте к любой из них. Например: http://www.mbus.org/

Какую порекомендовать не знаю, сам всего пару их видел.

> но как бы знаешь, писать врапперы, направленные под специфические задачи
если бы ты был внимателен, то увидел бы, что я враперов не советовал.

> (да, я считаю udp специфической задачей, за всё время программирования я его так и не попробовал. да, увы!) имхо уже не стоит.
для всего, что ориентировано на сообщения а не поток данных, лучше подходит удп (это обобщение, бывают и исключения). то, что ты его не пробовал, говорил об одном из трех: либо ты на самом деле не знаешь, как работают сетевые протоколы и когда какие лучше применять, либо тебе не попадалась задача на удп, либо ты просто мало писал.

> tcp до сих пор является наиболее распространенным протоколом в сетевых приложениях
4.2 разным приложениям нужен разный сервис. поэтому транспортный протокол - не один.

>для всего, что ориентировано на сообщения а не поток данных, лучше подходит удп (это обобщение, бывают и исключения).

2 my mind проблемы нужно решать по мере поступления, так что пока нет реалтайма или броадкастинга UDP нафиг не сдался. Лучше даже не голый TCP брать, а HTTP чтобы через прокси ходить.

еще зависит от допустимости задержки, так как хттп - это пять пакетов на запрос, то есть в среднем 500мс, еще непонятно сколько на передачу и четыре на разрыв. а с удп было бы только два на все про все.
2ОП: все, как видишь, зависит от задачи.

оу, i missed
> реалтайма

>оу, i missed >> реалтайма

Ну в реалтайме важно не столько количество пакетов а то что если пакет не пришел вовремя то его можно и нужно сразу выкинуть, т.к он уже неправильный. Это допустимо для передачи мультимедиа по сети, но не годится для сервисов типа RPC где нужен канал с гарантированной доставкой.

Apache Portable Runtime.

http://apr.apache.org

да, а еще не все реалтаймовые приложения ориентированы на длительное соединения, для некоторых важна возможность передать *сразу* (просто я именно такое приложение делал, поэтому это сразу вспомнил). Anyway, есть RTP.
ладно, это все оффтопик.