Аннотация:
Сокеты предоставляют весьма мощный и гибкий механизм межпроцессного взаимодействия (IPC). Они могут использоваться для организации взаимодействия программ на одном компьютере, по локальной сети или через Internet, что позволяет вам создавать распределённые приложения различной сложности. Кроме того, с их помощью можно организовать взаимодействие с программами, работающими под управлением других операционных систем. Например, под Windows существует интерфейс Window Sockets, спроектированный на основе socket API. Ниже мы увидим, насколько легко можно адаптировать существующую Unix-программу для работы под Windows.
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
Здравствуйте, Александр Шаргин, Вы писали:
АШ>Статья:
АШ>Авторы: АШ> Александр Шаргин
АШ>Аннотация: АШ>Сокеты предоставляют весьма мощный и гибкий механизм межпроцессного взаимодействия (IPC). Они могут использоваться для организации взаимодействия программ на одном компьютере, по локальной сети или через Internet, что позволяет вам создавать распределённые приложения различной сложности. Кроме того, с их помощью можно организовать взаимодействие с программами, работающими под управлением других операционных систем. Например, под Windows существует интерфейс Window Sockets, спроектированный на основе socket API. Ниже мы увидим, насколько легко можно адаптировать существующую Unix-программу для работы под Windows.
хорошая статья, особенно для начинающих( все это есть в юниксовом мануле ), наконец-то написали про select,
жаль вот мало про "сырые сокеты".
Здравствуйте, achmed, Вы писали:
A>хорошая статья, особенно для начинающих( все это есть в юниксовом мануле ), наконец-то написали про select, A>жаль вот мало про "сырые сокеты".
Чтобы выдрать всё описанное в статье, включая все примеры, из мануалов, придётся здорово потрудиться, а здесь всё в одном месте — для начинающих то, что надо. Конечно, для более продвинутых самое интересное начинается там, где статья кончается, но тут уже ничего не поделаешь — нельзя угодить всем сразу.
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
спасибо
интересно
понятно
несмотря на то, что пишу под виндой, все почти почти похоже и помогает разобраться и понять механизм
вот только мало про формирование заголовков
не подскажете где и что можно почитать подробнее?
АШ>Авторы: АШ> Александр Шаргин
АШ>Аннотация: АШ>Сокеты предоставляют весьма мощный и гибкий механизм межпроцессного взаимодействия (IPC). Они могут использоваться для организации взаимодействия программ на одном компьютере, по локальной сети или через Internet, что позволяет вам создавать распределённые приложения различной сложности. Кроме того, с их помощью можно организовать взаимодействие с программами, работающими под управлением других операционных систем. Например, под Windows существует интерфейс Window Sockets, спроектированный на основе socket API. Ниже мы увидим, насколько легко можно адаптировать существующую Unix-программу для работы под Windows.
Использование низкоуровневых сокетов
второй абзац: ... через UPD-сокет <- ага и через CTP/PI протокол =)
АШ>Авторы: АШ> Александр Шаргин
АШ>Аннотация: АШ>Сокеты предоставляют весьма мощный и гибкий механизм межпроцессного взаимодействия (IPC). Они могут использоваться для организации взаимодействия программ на одном компьютере, по локальной сети или через Internet, что позволяет вам создавать распределённые приложения различной сложности. Кроме того, с их помощью можно организовать взаимодействие с программами, работающими под управлением других операционных систем. Например, под Windows существует интерфейс Window Sockets, спроектированный на основе socket API. Ниже мы увидим, насколько легко можно адаптировать существующую Unix-программу для работы под Windows.
Маленькое замечание: создается впечатление, что в связке с select идут неблокирующие сокеты.
Замечание побольше: опять-таки в связке с select слушающий сокет требует более нежного обращения.
1. Для TCP close() сокета разрывает соединение только в том случае, если счетчик ссылок у файлового дескриптора == 1. В противном случае close() просто уменьшает счетчик ссылок не закрывая соединения. Чтобы гарантированно закрыть соединение независимо от количества ссылок дескриптора используется вызов shutdown().
2. Нет ни слова про TCP graceful close; почему возникает recv() == -1 && errno == ECONNRESET...
АШ>Авторы: АШ> Александр Шаргин
АШ>Аннотация: АШ>Сокеты предоставляют весьма мощный и гибкий механизм межпроцессного взаимодействия (IPC). Они могут использоваться для организации взаимодействия программ на одном компьютере, по локальной сети или через Internet, что позволяет вам создавать распределённые приложения различной сложности. Кроме того, с их помощью можно организовать взаимодействие с программами, работающими под управлением других операционных систем. Например, под Windows существует интерфейс Window Sockets, спроектированный на основе socket API. Ниже мы увидим, насколько легко можно адаптировать существующую Unix-программу для работы под Windows.
Под WinNT дескрипторы сокетов это почти вполне нормальные файловые дескрипторы с возможностью ReadFile и WriteFile (правда незачем
[]
> Под WinNT дескрипторы сокетов это почти вполне нормальные файловые дескрипторы с возможностью ReadFile и WriteFile (правда незачем
Под unix'ом дескриптор сокета и есть дескриптор файла. Очень мощная концепция — все есть файл. Самый тривиальный пример использования — CGI интерфейс, когда стандартный поток вывода — файловый дескриптор 1, есть сокет клиентского соединения.
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[3]: Программирование сокетов в Linux
От:
Аноним
Дата:
06.05.05 12:17
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>NeuroVirus wrote:
ME>[]
>> Под WinNT дескрипторы сокетов это почти вполне нормальные файловые дескрипторы с возможностью ReadFile и WriteFile (правда незачем
ME>Под unix'ом дескриптор сокета и есть дескриптор файла. Очень мощная концепция — все есть файл. Самый тривиальный пример использования — CGI интерфейс, когда стандартный поток вывода — файловый дескриптор 1, есть сокет клиентского соединения.
ME>-- ME>Maxim Yegorushkin
Ну и отлично, под IIS тоже так-же можно писать CGI, сам писал консольки на Дельфи и запускал под IIS4
Вполне можно написать сервер и запускать консольные приложения в качестве дочерних, с передачей сокета на StdIn/Out/Err,
правда немного мудреный способ наследования хендлов, но работает (кое-как, правда, но зачем это городить в виндах)
wrote:
> Здравствуйте, MaximE, Вы писали: > > ME>NeuroVirus wrote: > > ME>[] > >>> Под WinNT дескрипторы сокетов это почти вполне нормальные файловые дескрипторы с возможностью ReadFile и WriteFile (правда незачем > > ME>Под unix'ом дескриптор сокета и есть дескриптор файла. Очень мощная концепция — все есть файл. Самый тривиальный пример использования — CGI интерфейс, когда стандартный поток вывода — файловый дескриптор 1, есть сокет клиентского соединения. > > Ну и отлично, под IIS тоже так-же можно писать CGI, сам писал консольки на Дельфи и запускал под IIS4 > Вполне можно написать сервер и запускать консольные приложения в качестве дочерних, с передачей сокета на StdIn/Out/Err, > правда немного мудреный способ наследования хендлов, но работает (кое-как, правда, но зачем это городить в виндах)
Не в CGI дело.
Передай мне в select на виндозе дескриптор сокета, файла, пайпы...
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[5]: Программирование сокетов в Linux
От:
Аноним
Дата:
06.05.05 13:08
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>wrote:
>> Здравствуйте, MaximE, Вы писали: >> >> ME>NeuroVirus wrote: >> >> ME>[] >> >>>> Под WinNT дескрипторы сокетов это почти вполне нормальные файловые дескрипторы с возможностью ReadFile и WriteFile (правда незачем >> >> ME>Под unix'ом дескриптор сокета и есть дескриптор файла. Очень мощная концепция — все есть файл. Самый тривиальный пример использования — CGI интерфейс, когда стандартный поток вывода — файловый дескриптор 1, есть сокет клиентского соединения. >> >> Ну и отлично, под IIS тоже так-же можно писать CGI, сам писал консольки на Дельфи и запускал под IIS4 >> Вполне можно написать сервер и запускать консольные приложения в качестве дочерних, с передачей сокета на StdIn/Out/Err, >> правда немного мудреный способ наследования хендлов, но работает (кое-как, правда, но зачем это городить в виндах)
ME>Не в CGI дело.
ME>Передай мне в select на виндозе дескриптор сокета, файла, пайпы...
ME>-- ME>Maxim Yegorushkin
On Sun, 08 May 2005 01:25:26 +0400, А почему вы спрашиваете"" <39610@users.rsdn.ru> wrote:
> Здравствуйте, MaximE, Вы писали: > > ME>Передай мне в select на виндозе дескриптор сокета, файла, пайпы... > > Ооо. Богатая тема. Предлагаю передать в обычный юниксный select индентификатор SysV семафора.
Есле мне это понадобится в коде, где основной цикл на событиях готовности файловых дескрипторов, я подниму поток, который дождется семафора и просигнализирует это событие записью в пайп/сокетпэир, другой конец которого у меня в основном потоке в select/.../epoll.
Здравствуйте, MaximE, Вы писали:
ME>On Sun, 08 May 2005 01:25:26 +0400, А почему вы спрашиваете"" <39610@users.rsdn.ru> wrote:
>> Здравствуйте, MaximE, Вы писали: >> >> ME>Передай мне в select на виндозе дескриптор сокета, файла, пайпы... >> >> Ооо. Богатая тема. Предлагаю передать в обычный юниксный select индентификатор SysV семафора.
ME>Есле мне это понадобится в коде, где основной цикл на событиях готовности файловых дескрипторов, я подниму поток, который дождется семафора и просигнализирует это событие записью в пайп/сокетпэир, другой конец которого у меня в основном потоке в select/.../epoll.
Так оно и делается, чаще всего. Но это не отменяет того факта, что это прыжки и ужимки. Это настолько глупо, что не удается даже сделать вид, что за этим стоит какая-то глубокая философия. Это просто misfeature.
On Sun, 08 May 2005 02:17:58 +0400, А почему вы спрашиваете"" <39610@users.rsdn.ru> wrote:
>>> Здравствуйте, MaximE, Вы писали: >>> >>> ME>Передай мне в select на виндозе дескриптор сокета, файла, пайпы... >>> >>> Ооо. Богатая тема. Предлагаю передать в обычный юниксный select индентификатор SysV семафора. > > ME>Есле мне это понадобится в коде, где основной цикл на событиях готовности файловых дескрипторов, я подниму поток, который дождется семафора и просигнализирует это событие записью в пайп/сокетпэир, другой конец которого у меня в основном потоке в select/.../epoll. > > Так оно и делается, чаще всего. Но это не отменяет того факта, что это прыжки и ужимки. Это настолько глупо, что не удается даже сделать вид, что за этим стоит какая-то глубокая философия. Это просто misfeature.
На мой взгляд, все логично.
Файл — это то, что можно использовать в операциях ввода/вывода — read()/write(). Мне сложно представить, что и как ты собрался писать/читать в семафор. С другой стороны, очень логично, что дескриптор shared memory (упомянутый тобой POSIX realtime) — файл.
Здравствуйте, MaximE, Вы писали:
>>>> ME>Передай мне в select на виндозе дескриптор сокета, файла, пайпы... >>>> >>>> Ооо. Богатая тема. Предлагаю передать в обычный юниксный select индентификатор SysV семафора. >> >> ME>Есле мне это понадобится в коде, где основной цикл на событиях готовности файловых дескрипторов, я подниму поток, который дождется семафора и просигнализирует это событие записью в пайп/сокетпэир, другой конец которого у меня в основном потоке в select/.../epoll. >> >> Так оно и делается, чаще всего. Но это не отменяет того факта, что это прыжки и ужимки. Это настолько глупо, что не удается даже сделать вид, что за этим стоит какая-то глубокая философия. Это просто misfeature.
ME>На мой взгляд, все логично.
ME>Файл — это то, что можно использовать в операциях ввода/вывода — read()/write(). Мне сложно представить, что и как ты собрался писать/читать в семафор. С другой стороны, очень логично, что дескриптор shared memory (упомянутый тобой POSIX realtime) — файл.
Причем тут read/write? Системные вызовы select(2) и poll(2) — это API для синхронного мультиплексирования событий. Идея от том, что события бывают только на файловых дескрипторах (ну и сигналы, конечно), порочна и порождает это уродство с отдельным служебным потоком, преобразующем события на семафоре в события на fd.
Кстати насчет сигналов, select(2) крив и в отношении сигналов, что заставило избрести pselect(2). Но в линуксе, last time I checked, pselect(2) хоть и присутствует, но race не устраняет. Понятно, этому тоже есть объезд, но кривой.
В общем все не так гладко и красиво, как хотелось и могло бы быть, если б юникс был спроектирован, а не мутировал из запускалки для star trek'а.
On Sun, 08 May 2005 14:15:42 +0400, А почему вы спрашиваете"" <39610@users.rsdn.ru> wrote:
[]
> ME>Файл — это то, что можно использовать в операциях ввода/вывода — read()/write(). Мне сложно представить, что и как ты собрался писать/читать в семафор. С другой стороны, очень логично, что дескриптор shared memory (упомянутый тобой POSIX realtime) — файл. > > Причем тут read/write? Системные вызовы select(2) и poll(2) — это API для синхронного мультиплексирования событий. Идея от том, что события бывают только на файловых дескрипторах (ну и сигналы, конечно), порочна и порождает это уродство с отдельным служебным потоком, преобразующем события на семафоре в события на fd.
> Кстати насчет сигналов, select(2) крив и в отношении сигналов, что заставило избрести pselect(2). Но в линуксе, last time I checked, pselect(2) хоть и присутствует, но race не устраняет. Понятно, этому тоже есть объезд, но кривой.
В современном коде select мало кто пользует. Это портабельный, но морально устаревший механизм.
> В общем все не так гладко и красиво, как хотелось и могло бы быть, если б юникс был спроектирован, а не мутировал из запускалки для star trek'а.
Я доволен жизнью вообще и Linux'ом в частности, тем более, что лучше ничего нет — Linux был и остается state-of-the-art bleeding-edge. Что-то не устраивает — приложись и реализуй, будет тебе почет.
--
Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9
Re[11]: Программирование сокетов в Linux
От:
Аноним
Дата:
08.05.05 10:40
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>В современном коде select мало кто пользует. Это портабельный, но морально устаревший механизм.
Упс. А что используют? Просветите, тема актуальная для меня. Спасибо.
Здравствуйте, MaximE, Вы писали:
>> Кстати насчет сигналов, select(2) крив и в отношении сигналов, что заставило избрести pselect(2). Но в линуксе, last time I checked, pselect(2) хоть и присутствует, но race не устраняет. Понятно, этому тоже есть объезд, но кривой.
ME>В современном коде select мало кто пользует. Это портабельный, но морально устаревший механизм.
У poll(2) та же самая проблема.
>> В общем все не так гладко и красиво, как хотелось и могло бы быть, если б юникс был спроектирован, а не мутировал из запускалки для star trek'а.
ME>Я доволен жизнью вообще и Linux'ом в частности, тем более, что лучше ничего нет
Хехе. Юникс — плохая система, но остальные еще хуже, согласен. Но это не оправдывает всего того исторически слежавшегося мусора, который мы наблюдаем на этой феерической помойке.
> — Linux был и остается state-of-the-art bleeding-edge. Что-то не устраивает — приложись и реализуй, будет тебе почет.
"Приложись" — это в смысле придумай новое API? Ну, более вменяемые варианты этого велосипеда уже изобретены, kqueue(2) из FreeBSD, например. Он хотя бы расширяем безболезненно. Другое дело, что это не стандартно и стандартом никогда не станет.
но тут уже ничего не поделаешь — нельзя угодить всем сразу.
