Здравствуйте, AndrewVK, Вы писали:
AVK>А ты знаком, что советуешь ему блокирующие методы?
Знаком. Я посоветовал ровно то, что вопрошал автор:
Вопрос: нет ли в NET готового сетевого слушателя, чтобы работал как Timer — создал, подписался на событие о поступлении инфы, подключился и счастлив?
Какой конкретно недостаток блокирующих сокетов не соответствует поставленному вопросу?? Всю проблему раздули вы, прибежав со своей асинхронностью и эфемерными проблемами производительности (даже не думая о конкретной проблеме).
Здравствуйте, mDmitriy, Вы писали:
D>BeginReceive требует указания количества считываемых байт, а где их взять?
Ну если речь идет о XMPP поверх TCP, то ни откуда. Ведь TCP потоковый транспорт а XMPP — xml-текстовый протокол.
D>У меня считывается xml по jabber-протоколу через NetworkStream прямо в XMLReader. Все хорошо, если бы не цикл в потоке.
ну а в чем проблема?
читаешь в буфер, из буфера в свой XMLReader, снова читашь в буфер.
Здравствуйте, <Аноним>, Вы писали:
А>Ну там 20 строчек.
Это многопоточный код, там и в 20 строчек надо внимательно вчитываться.
А>Мне кажется вы мало опыта имеет с IOCP.
А мне кажется, что кое кто явно перешел на личности от недостатка аргументов.
А> Поэтому не знаете этих особенностей. Я вот тоже до недавних пор не знал про эту фушку.
Про какую такую фушку? Про то что в один стрим не надо писать сразу с нескольких потоков без синхронизации? А в MSDN смотреть не пробовал?
Read and write operations can be performed simultaneously on an instance of the NetworkStream class without the need for synchronization. As long as there is one unique thread for the write operations and one unique thread for the read operations, there will be no cross-interference between read and write threads and no synchronization is required.
IOCP тут совершенно не причем.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, mDmitriy, Вы писали:
D>Спасибо, но это уже тяжелые мотоциклы, хотя и готовые.
А обычный HTTP чем не подходит? Вся реализация в фреймворке есть искаропки, стандартный способ указания размера данных или конца данных тоже присутствует. Даже событийное асинхронное API есть — см. WebClient.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
WCF — да мы все его знаем и любим. Прикрутить к нему еще Protocol Buffers и совсем хорошо.
Thrift — прост и легок как две копейки, из минусов однонаправленный. Дуплекс просто не делается
ZeroMQ — просто швейцарский нож по сокетам. Решает проблемы с потерей связи, дослыкой, буферизацией, броадкастингом — этот велосипед не онин год самому писать и допиливать. Очень быстр и с минимальным оверхедом по протоколу. Будет гарантированно доставлять мегабайты данных.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mDmitriy, Вы писали:
D>>Спасибо, но это уже тяжелые мотоциклы, хотя и готовые.
AVK>А обычный HTTP чем не подходит? Вся реализация в фреймворке есть искаропки, стандартный способ указания размера данных или конца данных тоже присутствует. Даже событийное асинхронное API есть — см. WebClient.
Я работаю с jabber'ом... наверное, надо было сразу это указать, но как-то не придал значения.
