Здравствуйте, m2l, Вы писали:
m2l>Здравствуйте, reversecode, Вы писали:
DTF>>>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток? R>>да так и будет m2l>Не так не будет. Вы вводите человека в заблуждение. m2l>См.: m2l>IEEE Std 1003.1, 2004 Edition: For message-based sockets, such as SOCK_RAW, SOCK_DGRAM, and SOCK_SEQPACKET, the entire message shall be read in a single operation. m2l>man 2 socket: SOCK_DGRAM and SOCK_RAW sockets allow sending of datagrams to correspondents named in sendto(2) calls. Datagrams are generally received with recvfrom(2), which returns the next datagram along with the address of its sender. m2l>MSDN: recvfrom function: The recvfrom function receives a datagram and stores the source address.
уже ниже по теме разобрались
m2l>И дальнейшее апеллирование к mbuf в корне неверно. R>>куда читаете туда и уйдет R>>какой вообще смысл использовать recvfrom на одном сокете с разных потоков ? R>>как вы потом те данные клеить будете ? m2l>Если дейтаграмы можно обрабатывать параллельно, то всё это приемлемо масштабируется.
треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме
R>>вообще нужно уточнять винда или юникс, у них все по разному устроено m2l>Логика работы того API что скопировали у BSD у них отличается разве что в shutdown/close. Всё остальное поразительно идентично.
Здравствуйте, reversecode, Вы писали:
R>треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме
Потокобезопасность не гарантирует наличия данных... Это как бы из разной оперы вещи...
R>я про IOCP а не про обмазанный posix сверху
А библиотека SOCKETS работает на уровне POSIX
N_C>Ну так а я о чем? Только это буфер, который Вы передали в recvfrom... N_C>По-моему Вы путаетесь в буферах... А их там много — на каждом уровне свои. Ethernet, IP, UDP, SOCKET... N_C>И на каждом уровне датаграмма (или что-то иное) своя. И пока на очередном уровне не будет принята полностью датаграмма вышележащего уровня она не поднимается вверх.
я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю
в контексте кернел буфера, я имел ввиду уже распаковку данных дейтаграммы для подготовки в буфер откуда уже данные уйдут юзер левел
понятно что если не хватило памяти или ошибка на езернет или айпи уровне то юзеру что то та говорить смысла нет, все в тихую мочится
Pzz>Это внутренние проблемы ОС. recvfrom() из датаграмного сокета делает одно из двух: либо вычитывает одну целую датаграмму, либо возвращает ошибку. Датаграмма никогда не бьется между двумя последовательными recииииvfrom()
читаем по теме, либо читает максимально заданный размер который ей сказали
а то в вашем случае она вернет ошибку, что в корне не верно
вообще мне ничего объяснять не надо, я с ядром на ты
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>треад сейф еще не означает что два потока могут вызвать recvfrom и сразу получить по дейтаграмме N_C>Потокобезопасность не гарантирует наличия данных... Это как бы из разной оперы вещи...
я говорил о том что если один поток вошел в recvfrom, то второй может сидеть и ждать пока первый выйдет
в таком контексте вообще смысла нет по потокам раскидывать
R>>я про IOCP а не про обмазанный posix сверху N_C>А библиотека SOCKETS работает на уровне POSIX
а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP
Здравствуйте, reversecode, Вы писали:
Pzz>>Это внутренние проблемы ОС. recvfrom() из датаграмного сокета делает одно из двух: либо вычитывает одну целую датаграмму, либо возвращает ошибку. Датаграмма никогда не бьется между двумя последовательными recииииvfrom()
R>читаем по теме, либо читает максимально заданный размер который ей сказали
Эту фразу понять нельзя
recvfrom никогда не бьет датаграмму между двумя своими вызовами. Конкретно для UDP и венда и unix, насколько я помню, если буфер слишком маленький, молча обрежут датаграмму. Для других типов датаграмных сокетов могут вместо этого и ошибку вернуть. Но на два read'а датаграмму не разрежут.
R>а то в вашем случае она вернет ошибку, что в корне не верно R>вообще мне ничего объяснять не надо, я с ядром на ты
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>в никсах они не iocp R>>а в винде posix лежит сверху iocp насколько я знаю, т.е. емуляция N_C>А какая разница? recvfrom где где, а на Винде уж точно работает именно так, как я написал.
ну ? а я сказал о том что есть еще сокеты IOCP
автор не уточнял какие он использует, а я в первом ответе намекнул что если виндовые но не posix — то все может быть по другому
R>>автор не уточнил какая ос и какие функции R>>но с IOCP есть мысли что будет работать все по другому, ну т.е. там винда сама все по потокам раскидает N_C>recvfrom — это POSIX вроде как...
само собой
R>>вообще еще в никсах есть recvmsg, так что может есть смысл с ими поиграться для ловли большего числа буферов N_C>Каких буферов, извините? Есть входящий буфер сокета и туда складываются датаграммы. Их не одна, не две а много...
пользовательский буфер
если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете
R>я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю
Я с самого начала говорил про то, что или копируется в буфер recvfrom или отбрасывается. Вы приплели какие-то mbuf и прочее...
А когда Вы зашли в Гугл прочитали про то, что я сказал опять не поняли, про какой буфер идет речь...
R>в контексте кернел буфера, я имел ввиду уже распаковку данных дейтаграммы для подготовки в буфер откуда уже данные уйдут юзер левел
Я Вам уже указывал, что на каждом уровне свои буферы... И на каждом уровне свои правила. И с самого начала я говорил про правила работы функции recvfrom
R>понятно что если не хватило памяти или ошибка на езернет или айпи уровне то юзеру что то та говорить смысла нет, все в тихую мочится
Вот только к вопросу автора темы это не имеет отношения от слова совсем
R>читаем по теме, либо читает максимально заданный размер который ей сказали R>а то в вашем случае она вернет ошибку, что в корне не верно
Нет, не в корне... Она скопирует то, что можно и все-таки вернет ошибку.
R>вообще мне ничего объяснять не надо, я с ядром на ты
Зато с верхним API Сокетов Вы не очень разбираетесь, уж извините.
Здравствуйте, reversecode, Вы писали:
R>на два не бьет, уже давно разобрались R>но читать меньше чем было принято в сокет — можно, остальное отбросится навсегда(если верить гуглу)
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>я в буферах не путаюсь, это вы запутались о каких буферах я каждый раз говорю N_C>Я с самого начала говорил про то, что или копируется в буфер recvfrom или отбрасывается. Вы приплели какие-то mbuf и прочее... N_C>А когда Вы зашли в Гугл прочитали про то, что я сказал опять не поняли, про какой буфер идет речь...
вашими словами это выглядит как если буфер в который читаем будет меньше — то отбросится
что уже заставило сомневаться
не отбрасывается, а читается размером с буфер, а остальная часть отбрасывается
про mbuf были просто развитие темы в которую вы начали тянуть))
Здравствуйте, reversecode, Вы писали:
R>а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP
функция recvfrom относится к POSIX...
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, reversecode, Вы писали:
R>>а автор не уточнял какими сокетами он пользуется )) в винде есть они и IOCP N_C>функция recvfrom относится к POSIX...
я и не отрицал что она не posix
лучше скажите как с форума удалится с контентом, уже пол года прошу модераторов а они меня не отпускают
Здравствуйте, reversecode, Вы писали:
R>если recvmsg позволяет сразу забирать по 5 дейтаграм, это лучше чем два потока будут пихаться в один recvfrom на одном сокете
Вы с "параллельными" алгоритмами обработки данных знакомы? Забрать 5 сразу и потом их по очереди лопатить не всегда будет лучше, чем сделать в одном потоке забор по одной датаграмме и запустить столько потоков, сколько надо для скорости.
Почему Вы считаете, что поток только делает, что забирает датаграммы? он же их еще обработать должен. Вот, пока он обрабатывает можно и другим потоком читать.
Здравствуйте, DTF, Вы писали:
DTF>Коллеги, привет. DTF>Подскажите, пожалуйста, можно ли из нескольких потоков читать данные из одного и того же UDP-сокета?
Можно, будет работать безопасно. Но не очень быстро, так как блокировки в ядре будут съедать время.
В Линуксе более правильно в каждом потоке создать свой сокет с SO_REUSEPORT и повесить их на один и тот же порт. Ядро будет пытаться отправить потоки пакетов в детерминированные сокеты в зависимости от тройки получатель/отправитель/порт: https://lwn.net/Articles/542629/
Здравствуйте, DTF, Вы писали:
DTF>Коллеги, привет. DTF>Подскажите, пожалуйста, можно ли из нескольких потоков читать данные из одного и того же UDP-сокета? DTF>Будут ли данные потеряны и/или повреждены? DTF>И какую документацию можно на эту тему почитать?
DTF>Я смог нагуглить, что recv/recvfrom являются потокобезопасными, т.е. их можно вызывать одновременно. DTF>Но что будет с данными, которые они читают? DTF>Не будет ли так, что один кусок датаграммы уйдет в один поток, а другой кусок — в другой поток?
Можно, но глупо. Лучше читать в одном и распределять по потокам, как положено. Или создать несколько сокетов на одном порту и получать на каждый по копии датаграммы, можно даже в разных процессах. Вот только зачем все это? В скорость получения данных никогда ничего не упиралось, скорее в скорость передачи.
