Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Код в студию можно?
Использование Socket'ов для IPC под Windows — это зло. Даже обмен виндовыми сообщениями вида WM_COPY и то будет эффективнее и удобнее, в том числе и для пользователей. Антивирусы, брандмауэры — смысл заставлять эту братию волноваться, если вы хотите всего-лишь обменяться данными и вас даже не интересует сеть как таковая?
Я не знаю какие у вас задачи, но в моих задачах две программы могут быть установлены как на одном, так и на разных компьютерах. Универсальный вариант, такой как сокеты, не может ни привлекать.
С другой стороны,
server.Bind(new IPEndPoint(IPAddress.Any, 5000));
всполошил брендмауер, а такой
server.Bind(new IPEndPoint(IPAddress.Loopback, 5000));
нет. Хотя, антивирус даже с IPAddress.Loopback что-то проверял.
С другой стороны,
server.Bind(new IPEndPoint(IPAddress.Any, 5000));
всполошил брендмауер, а такой
server.Bind(new IPEndPoint(IPAddress.Loopback, 5000));
нет. Хотя, антивирус даже с IPAddress.Loopback что-то проверял.
IPAddress.Loopback = Localhost?
Понятное дело, WM_COPY для IPC между машинами не пойдет. На каждую ситуацию свой вариант, к тому же форма IPC должна быть опциональна, имхо. Юзер должен иметь возможность переключиться с pipes на sockets и наоборот.
Понятное дело, WM_COPY для IPC между машинами не пойдет. На каждую ситуацию свой вариант, к тому же форма IPC должна быть опциональна, имхо. Юзер должен иметь возможность переключиться с pipes на sockets и наоборот.
А разве именованные каналы не имеют возможности между разными машинами данные передавать?
(или я коммент неправильно понял?)
(или я коммент неправильно понял?)
Автор не отрицает этого, по-моему. Дают само собой. Но самое важное при удаленке — давать выбор. Так делает тот же MS SQL Server.
TCP сокеты гораздо эффективнее, у именованных каналов передача информации полностью синхронная.
А можно те же замеры, но на гигабитной сетке (или с виртуальной машиной)?
А выводы, как раз у Вас другие получились: 160 против 755 (сокеты против каналов).
А выводы, как раз у Вас другие получились: 160 против 755 (сокеты против каналов).
В каком смысле «полностью синхронная»? Вообще то в NT весь ввод/вывод асинхронный (синхронные операции на самом деле это асинхронные + ожидание окончания). Ну а именованные каналы — это обычная файловая система (\Device\NamedPipe который создается, если не ошибаюсь в npfs.sys) и соответственно с ними работают любые асихронные операции: от обычных GetOverlappedResult и Read/WriteFileEx до IOCP.
Или Вы что-то другое имели в виду?
Или Вы что-то другое имели в виду?
Я имел ввиду что следующий блок данных передаётся только после того, как придёт подтверждение иб успешном приёме предыдущего.
Про файловую систему это ни о чем не говорит, потому что сокеты тоже «наследуются» от файлов (в том смысле что с ними можно работать через Read/WriteFile)
Нет, вообще то говорит. NPFS (Named Pipe File System) — это именно что файловая система. Read/WriteFile поддерживает и пр., а вот сокеты — раньше были ПАРОЙ файлов (\Device\Tcp, \Device\Udp и прочих TDI устройств) и вся работа с ними производилась через IOCTL-ы (тоже впрочем асинхронные, как и весь ввод/вывод в NT), а IRP_MJ_READ/IRP_MJ_WRITE этими устройствами даже не поддерживаются. Сейчас, с появлением WSK, все еще интереснее — файлы там не фигурируют вообще (хотя стоит признать, в новой модели я разбираюсь чуть слабее — может и пропустил чего).
В общем я тут умничал только для того, чтобы сказать, что именованые каналы — это обычные файлы с точки зрения как ядерного API, так и Win32 подсистемы, а вот сокеты — это совсем не обычные файлы, я бы даже сказал совсем необычные.
В общем я тут умничал только для того, чтобы сказать, что именованые каналы — это обычные файлы с точки зрения как ядерного API, так и Win32 подсистемы, а вот сокеты — это совсем не обычные файлы, я бы даже сказал совсем необычные.
TCP-сокеты изначально тоже синхронны, если не использовать асинхронных «обёрток».
А это тогда что-за хрень?
en.wikipedia.org/wiki/Sliding_Window_Protocol
en.wikipedia.org/wiki/Sliding_Window_Protocol
Так и именованные каналы легко пересекают границы машин.
"\\.\pipe\PipeName" versus "\\remote-machine-name\pipe\PipeName"
Для C# нужно использовать версии конструкторов с указанием имени сервера. Например:
public NamedPipeClientStream(
string serverName,
string pipeName
)
"\\.\pipe\PipeName" versus "\\remote-machine-name\pipe\PipeName"
Для C# нужно использовать версии конструкторов с указанием имени сервера. Например:
public NamedPipeClientStream(
string serverName,
string pipeName
)
И требует чтобы окна всегда были с нами. Сейчас это так, но такими темпами сборки винды без user-подсистемы так и останутся мечтой.
Я бы даже сказал, в одной сессии. И то, начиная с Windows Vista могут возникнуть проблемы с уровнем изоляции окон (окно с более низким уровнем привилегий не может передать WM-сообщение окну с более высоким уровнем).
Ну не в 5 раз :-)
Вместо Java — C попробуйте.
Я Java тут никогда не было :-) Да и 2/3 в ядре, большой разницы не будет.
Вы не поняли. Имелась в виду пропорция
TCP/UDP = Java/C
TCP/UDP = Java/C
Ну и ладно) using не увидел, а без него для меня это ява) Насчет того что следует использовать UDP это очень дельный совет, использование TCP тут абсолютно избыточно, на лупбэке не теряются пакеты...) А прирост производительности может быть и в полтора и в два раза.
Вполне прогнозируемый результат. Локально пайпам не требуется инкапсулироваться в сетевые протоколы и проходить через фильтры. По сети картина должна быть обратной, потому что пайпы помимо своих механизмов управления, инкапсулируют данные в сеть.
Примерно так: [ IP | TCP [ NetBios [ SMB ( pipes data ) ] ] ]
Примерно так: [ IP | TCP [ NetBios [ SMB ( pipes data ) ] ] ]
Хотелось бы узнать, как на уровне ФС в виндовс эти пайпы ваши поддерживаются, я имею ввиду, отличается ли пайп от обычного файла и чем в рамках ФС.
Например не поддерживают SetFilePointer
мне это ниочем не говорит) Я имел ввиду, можно ли пайп файл отличить от непайпа, или пайп это тупо файл в виндовс?
Пайп это совсем не файл — у него нет ни размера, например. Хендл пайпа может использоваться как хендл файла в функциях ReadFile и WriteFile. Имя именованного пайпа похоже на имя файла.
Можни сказать что «пайп это тупо файл». См. этот комментарий:
habrahabr.ru/blogs/system_programming/81067/#comment_2399951
habrahabr.ru/blogs/system_programming/81067/#comment_2399951
Строго говоря, это не различие. Файл на стримере тоже не поддерживает случайный доступ, но это файл.
И файл на диске, и пайп, и сокет это файловые объекты, потому что имеют одинаковою базовую структуру FILE_OBJECT, на которой основываются общие способы доступа ко всем этим объектам (если более точно — соответствующая структура пайпа начинается с тех же полей что есть в структуре файла и добавляет свои, что принято рассматривать как «наследование» объектов). Среди полей есть указатели на функции чтения и записи, которые отличаются для пайпов и файлов, но фокус в том, что они могут отличаться и у разных файловых объектов.
Поэтому можно сказать что пайп это файл.
И на последок:
msdn.microsoft.com/en-us/library/aa364960%28VS.85%29.aspx
Это описание функции GetFileType, среди возвращаемых начений есть FILE_TYPE_PIPE, что как бы намекает нам.
И файл на диске, и пайп, и сокет это файловые объекты, потому что имеют одинаковою базовую структуру FILE_OBJECT, на которой основываются общие способы доступа ко всем этим объектам (если более точно — соответствующая структура пайпа начинается с тех же полей что есть в структуре файла и добавляет свои, что принято рассматривать как «наследование» объектов). Среди полей есть указатели на функции чтения и записи, которые отличаются для пайпов и файлов, но фокус в том, что они могут отличаться и у разных файловых объектов.
Поэтому можно сказать что пайп это файл.
И на последок:
msdn.microsoft.com/en-us/library/aa364960%28VS.85%29.aspx
Это описание функции GetFileType, среди возвращаемых начений есть FILE_TYPE_PIPE, что как бы намекает нам.
внутри локалхоста, наверно, можно использовать SharedMemory эффективнее, нежели пайпы…
Ну это скорее для точно известных объемов данных, не для потока.
ой да бросьте… на этой базе сделать «поток» не представляет особых сложностей (собственно поток так и работает — буферами, если буферизированный, конечно же)… я даже где-то видел реализацию С++ на основе stl базового basic_ostream и basic_istream…
В общем вы правы, но это уже велосипед. Если «поток так и работает», то давайте его и использовать.
Кроме того для MMF нужно кроме самой памяти иметь какой-нить флажок для синхронизации (event например).
Я бы сказал что это поиск себе проблем на ровном месте. Другое дело, если нужно иметь расшареную структуру фиксированного размера, тут да, MMF рулит.
Кроме того для MMF нужно кроме самой памяти иметь какой-нить флажок для синхронизации (event например).
Я бы сказал что это поиск себе проблем на ровном месте. Другое дело, если нужно иметь расшареную структуру фиксированного размера, тут да, MMF рулит.
Пайпы как раз и используют shared memory на локалхосте. При этом избавляя от необходимости выполнять кучу рутинной работы по созданию, синхронизации и прочему менеджменту этой памяти. Дополнительным плюсом является возможность легкого разноса клиента с сервером на разные машины практически без изменения кода.
Интересно бы поглядеть на полно-дуплексный вариант. Не пробовали?
1) Почему не под Линуксом тесты, мне кажется идусская поделка для запуска игр не очень подходит для теста. Если сербезно — надо наверно тестировать серверные ОС, вряд ли на десктопе что-то понадобится передавать.
2) А почему пайпы не проверили? Которые cmd1 | cmd2
3) Почему на .NET написано, вы бы еще на яве писали, ей богу :) Надо хотя бы Си.
2) А почему пайпы не проверили? Которые cmd1 | cmd2
3) Почему на .NET написано, вы бы еще на яве писали, ей богу :) Надо хотя бы Си.
Извините, нет желания общаться с красноглазиками. Тестируйтеафриканскую ОС, а мне пока и индусской хватает.
Тоже плохо. Он не прав, но это не значит что Линукс — африканская ось.
А убунту это что?!
Ну это еще не весь линукс.
Sorry за офтопик, но…
Canonical Ltd.
Штаб-квартира: Лондон, Великобритания
Основатель: Марк Шаттлворт ( вот у него есть второе гражданство африканское )
Организация британская. И разрабов из стран третьего мира — меньшинство, а вот мелкомягкие любят рабов… к примеру американские стажёры.
Canonical Ltd.
Штаб-квартира: Лондон, Великобритания
Основатель: Марк Шаттлворт ( вот у него есть второе гражданство африканское )
Организация британская. И разрабов из стран третьего мира — меньшинство, а вот мелкомягкие любят рабов… к примеру американские стажёры.
1. Надо полагать мы сейчас имеем счастье общаться с экспертом в области проектирования ОС? Расскажите, пожалуйста, что Вы думаете о перспективах внедрения асинхронного ввода/вывода в линуксе. Для нас это очень важно.
2. Видно эксперта с мировым именем. Вы правда считаете, что пайпы cmd1 | cmd2 отличаются от тах, что были протестированы?
3. Оба теста на шарпе — имеем «apples to apples». Кроме того, большая часть времени была проведена в ядре, да и в юзермоде что то мне подсказывает, что CLR-слой там достаточно тонкий и все быстро уходит в нейтив.
2. Видно эксперта с мировым именем. Вы правда считаете, что пайпы cmd1 | cmd2 отличаются от тах, что были протестированы?
3. Оба теста на шарпе — имеем «apples to apples». Кроме того, большая часть времени была проведена в ядре, да и в юзермоде что то мне подсказывает, что CLR-слой там достаточно тонкий и все быстро уходит в нейтив.
1) А что, всякие select (ну да, он несовершенен) kqueue и epoll уже не считаются асинхронным вводам/выводом?
2) А что, именованный канал Windows и Linux pipe — одно и то же?
2) А что, именованный канал Windows и Linux pipe — одно и то же?
Ой, kqueue из FreeBSD, но это все равно что Линукс, тоже белые буквы на черном фоне в командной строке :)
1. Не считается. Это не асинхронный ввод/вывод, а ожидание момента, когда синхронный ввод/вывод можно произвести без блокировки. Асинхронный это: запустил операцию чтения и вышел — она выполняется в фоне. Я вообще то думал, что Вы вспомните libaio — и уже собирался понасмехаться, но не судьба :-)
По поводу фри — смешно. BSDisALinuxDistro™ ага. В винде тоже белые буквы на черном фоне в командной строке (даже POSIX сертификация есть) — винда тоже линукс? :-)
2. А где Вы видели такое утверждение? В винде «cmd1 | cmd2» использует те же пайпы (только анонимные — создаваемые CreatePipe вместо CreateNamedPipe), что и были протестированы. В линуксе «cmd1 | cmd2» использует пайпы, создаваемые вызовом pipe(2) — именовать их нельзя (для подобия именованых пайпов нужно использовать юникс домейн сокеты — правда очень консистентно?).
По поводу фри — смешно. BSDisALinuxDistro™ ага. В винде тоже белые буквы на черном фоне в командной строке (даже POSIX сертификация есть) — винда тоже линукс? :-)
2. А где Вы видели такое утверждение? В винде «cmd1 | cmd2» использует те же пайпы (только анонимные — создаваемые CreatePipe вместо CreateNamedPipe), что и были протестированы. В линуксе «cmd1 | cmd2» использует пайпы, создаваемые вызовом pipe(2) — именовать их нельзя (для подобия именованых пайпов нужно использовать юникс домейн сокеты — правда очень консистентно?).
А где нужно это ваше «асинхронное чтение»? Я могу понять, запись: отдал данные в буфер, и пусть их система потихоньку отдает (кстати это в Линуксе есть, см. вызов sendfile() ), а чтение-то зачем?
Например, обработка HTTP-запроса: там можно запускать обработчик после чтения первой строки, содержащей URL (ну и возможно, заголовка Host:, если он используется). Как тут применить асинхронное чтение? «Прочитай первые 2000 байт и возвращайся»? Дык задержка лишняя получается.
Например, обработка HTTP-запроса: там можно запускать обработчик после чтения первой строки, содержащей URL (ну и возможно, заголовка Host:, если он используется). Как тут применить асинхронное чтение? «Прочитай первые 2000 байт и возвращайся»? Дык задержка лишняя получается.
Вообще-то, учитывая что есть такие штуки как DMA, любой ввод-вывод: чтение/запись HDD, приём/передача LAN, по своей природе асинхронен.
Центральный процессор даёт устройству команду обработать некоторый кусок памяти, но чтение из памяти, а тем более обработка, выполняются уже в обход центрального процессора.
То есть на современной аппаратуре синхронный ввод-вывод это практически всегда запуск асинхронного и окончание его работы.
Центральный процессор даёт устройству команду обработать некоторый кусок памяти, но чтение из памяти, а тем более обработка, выполняются уже в обход центрального процессора.
То есть на современной аппаратуре синхронный ввод-вывод это практически всегда запуск асинхронного и окончание его работы.
Да-да, раз нет — значит не нужно. Продолжайте читать мантры про «запускалки для игр», ну а когда появится свободная минутка подумайте о том, что когда Вы выставлете асинхронную операцию чтения, вы сразу же предоставляете буфер, который можно залочить в физической памяти и передать в устройство, а устройство будет читать через DMA напрямую в Ваш буфер. Это первое, что пришло в голову. С select-ом все сначала считается во внутренние буферы, а потом скопируется.
Еще я могу выставить много асинхронных операций в одном потоке и дать каждой функцию, которая вызовется по завершению — удобно же. Да много чего можно сделать из того, что «не нужно».
Вообще select — это «как бы замена» асинхронных операций, но как обычно неполноценная. Подходит только для сокетов (потому что для обычных файлов «ready for reading» или «ready for writing» лишено смысла — они обречены оставаться блокирующими), жутко неудобны в использовании, да и send все так же блокирует.
Это все та же синхронная операция. Просто комбинация read и write. Даю хинт: асинхронные операции не блокируют вызывающий поток.
Вы почитайте про IO Completion Ports — авось перестанете нести чушь в публичных местах.
Еще я могу выставить много асинхронных операций в одном потоке и дать каждой функцию, которая вызовется по завершению — удобно же. Да много чего можно сделать из того, что «не нужно».
Вообще select — это «как бы замена» асинхронных операций, но как обычно неполноценная. Подходит только для сокетов (потому что для обычных файлов «ready for reading» или «ready for writing» лишено смысла — они обречены оставаться блокирующими), жутко неудобны в использовании, да и send все так же блокирует.
(кстати это в Линуксе есть, см. вызов sendfile()
Это все та же синхронная операция. Просто комбинация read и write. Даю хинт: асинхронные операции не блокируют вызывающий поток.
Как тут применить асинхронное чтение? «Прочитай первые 2000 байт и возвращайся»?
Вы почитайте про IO Completion Ports — авось перестанете нести чушь в публичных местах.
На всякий случай (чтобы Вы не воспринимали хинт слишком буквально) отмечу, что O_NONBLOCK не имеет ничего общего с асинхронным IO — просто вместо блокирования будет возвращаться ошибка EWOULDBLOCK (чего люди не придумают, лишь бы не писать на нормальном API).
Ну меня просто в первую очередь асинхронные операции с сокетами и интересовали, а у вас больше про файлы. А там трюки с DMA не пройдут, так как пакет от сетевой карты разбирается и анализируется по всякому. И опять же, с сокетами нужно сразу обрабатывать полученные данные, как только придет, допустим HTTP запрос, а не ждать, пока там N байт наберется.
Боже, какую чушь вы несёте с умным видом.
Описание одного из самых примитивных чипов:
wiki.osdev.org/Ne2000
Описание одного из самых примитивных чипов:
wiki.osdev.org/Ne2000
The Ne2000 network card uses two ring buffers for packet handling. These are circular buffers made of 256-byte pages that the chip's DMA logic will use to store received packets or to get received packets.
Вы сырые данные от сетевой карты прямо в userspace грузить будете? Или у них уже аппаратно встроен весь TCP стек?
А у нас в ядре тоже все асинхронно (в смысле в первую очередь потому что все асинхронно там, все асинхронно и выше). В отличие от. Но вы похоже не улавливаете суть. Если не доверяете «классовым врагам» — почитайте что пишут ваши же (вот прямо с первого раздела Motivation и начинайте).
О, самую мякотку пропустил.
Вы таки будете удивляться, но да. Причем я об этом уже упоминал
Ну и когда дойдете до раздела «Lack of support in Linux» остановитесь на секундочку и подумайте, может вместо выкрикивания лозунгов про «запускалки для игр» стоит заняться самообразованием?
Или у них уже аппаратно встроен весь TCP стек?
Вы таки будете удивляться, но да. Причем я об этом уже упоминал
Ну и когда дойдете до раздела «Lack of support in Linux» остановитесь на секундочку и подумайте, может вместо выкрикивания лозунгов про «запускалки для игр» стоит заняться самообразованием?
Именно для сетевых приложений тот же IOCP используется наиболее широко (хотя в тех же БД тоже нередко). И да, современные сетевые карты со скоростями передачи 1-10 gbps ТОЛЬКО DMA и используется (плюс куча других техник, типа того же TOE, которого в запускалке желейных окошек нет и не предвидится).
И, кстати, select — это неудобный и неполноценный КОСТЫЛЬ, а не асинхронный ввод-вывод.
2. Интересно, а давно mkfifo(3) отменили?
Понимаю, что некропост, но мне очень интересно.
А можно не насмехаться, а нормально рассказать в чем проявляются его недостатки и почему такое критическое мнение насчет этого?
Спрашиваю совершенно серьезно.
Я вообще то думал, что Вы вспомните libaio — и уже собирался понасмехаться, но не судьба :-)
А можно не насмехаться, а нормально рассказать в чем проявляются его недостатки и почему такое критическое мнение насчет этого?
Спрашиваю совершенно серьезно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IPC: сокеты против именованных каналов