Если его нет - уде хорошо

Memcpy бе выделения памяти не получится

и это - syscall

О том и речь

Да хрен с ними с сисколами и ядром. Главное, как память-то не выделять на каждое заходящее UDP, но читать его и долго потом думоть?

берёшь большой статический массив и в него читаешь|пишешь пакетики свои

и все это - безо всякого выделения памяти!

а главное - зачем? :)

если ядро операционной системы чем-то не устраивает, наверное, пора менять профессию, в конце концов :)

Или писать свой стек ТЦП/ИП прямо на Go, заворачивать весь траффик туда и там уже прямо без выдеения памяти можно делать что хочешь. Но проще профессию поменять :)

А скорей всего, и драйвера Ethernet придется самому писать...

Блин, что-то злые тут все сегодня, даже я :(

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

а прочитать как?

вариант на Go интересует как я понимаю?

Коллеги, вы странные

Коллеги, вы странные

в чем странность?

к словам придираемся, как дети малые, а это не по-хипстерски

А скорей всего, и драйвера Ethernet придется самому писать...

DPDK уже упоминали? Я не тыкал, но вот это выглядит интересно http://dpdk.org/doc/guides/prog_guide/mempool_lib.html

хипстеры обычно добрей, и о чем бы они не говорили, они всегда говорят "как бы" и делают доброе умное лицо

хипстеры обычно добрей, и о чем бы они не говорили, они всегда говорят "как бы" и делают доброе умное лицо

Вы перепутали с канадцами

то есть хипстерам все, как бы, глубоко монопенисуально на самом деле, так что нечего к слова цепляться!

а прочитать как?

buf := make([]byte, 4096) n, err := conn.Read(buf)

это выделение памяти!

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

ужос кокой! А если сразу два коннекта?

ужос кокой! А если сразу два коннекта?

на каждый коннект по буферу небольшому. bufio.NewReaderSize(conn, 4096)

можно так, можно через sync.pool еще буферы выделять и отдавать в пул как коннект закрывается

вариантов просто дофига

хипстеры обычно добрей, и о чем бы они не говорили, они всегда говорят "как бы" и делают доброе умное лицо

тащемта не все например

странные вы, коллеги. Человек же сказал - без выделения памяти. Зачем обсуждать тут всякие левые варианты?

да, так вот

странные вы, коллеги. Человек же сказал - без выделения памяти. Зачем обсуждать тут всякие левые варианты?

Я конечно новичок и мало что понимаю, но что если через канал оформить с селектом?

пришло - обработал

я повторюсь

вы странные

что нам возвращает ядро?

простите, я не хотел

оно возвращает нам указатель на буфер

с выделением памяти - это с копированием данных из буфера в наш собственный буфер

без выделения - это с использованием того буфера, что вернуло ядро

ну вот :( А говорят, на Go только хипстеры пишут. А они добрые и не зануды...

Нет) с осени прошлого года они запускают центр разработки в Москве. Ищут талантливых ребят с опытом смены стека. Предпочтение кандидатам с Go, так как они планируют новый сервис, он будет на go

а только фулстеки нужны? :)

без выделения - это с использованием того буфера, что вернуло ядро

не верно. использовать тот буфер, что использует ядро нельзя. чтобы считать из сокета нужно передать указатель на свой буфер и длину. другими словами не выделяя память считать из сокета что-либо нельзя в принципе (мои слова легко подтверждаются описанием сигнатуры функции recv в sys/socket.h)

не верно. использовать тот буфер, что использует ядро нельзя. чтобы считать из сокета нужно передать указатель на свой буфер и длину. другими словами не выделяя память считать из сокета что-либо нельзя в принципе (мои слова легко подтверждаются описанием сигнатуры функции recv в sys/socket.h)

коллега, вы путаете

Дайте мне ведерко с попкорном, пожалуйста!

коллега, вы путаете

что с чем? ядро буфер не возвращает никакой

можно я еще немножечко вброшу? ? https://github.com/golang/go/issues/3661

что с чем? ядро буфер не возвращает никакой

это вы просто не в курсе, как работает AIO

это вы просто не в курсе, как работает AIO

Скиньте ссылку людям на какое-то описание, так будет проще

да я вот гуглю что-то внятное, и пока не нагуглил

это вы просто не в курсе, как работает AIO

epoll/kqueue/iocp? не вкурсе только о kqueue. кроме обвязки (в сравнении с простой реализацией) все тоже самое чтение, что я описал выше - в recv отправляется указатель на буфер и длина и ядро в пользовательский буфер пишет данные из буфера сокета и возвращает кол-во записанных

ну так вот это не так

https://www.codeproject.com/Articles/13382/A-simple-application-using-I-O-Completion-Ports-an

https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/

держите по iocp и epool - читайте

http://yusufonlinux.blogspot.ru/2010/11/data-link-access-and-zero-copy.html

http://yusufonlinux.blogspot.ru/2010/11/data-link-access-and-zero-copy.html

ну сырые сокеты то зачем? про zero-copy тоже понравилось. какое отношение к AIO это имеет и что я в итоге не понимаю?

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

zero-copy повышает производительность сетевых серверов в разы, насколько я помню - memcpy очень дорогой, очень

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

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

ядро выделяет буфер, и читает данные в него

на самом деле не так ) пользователь предоставляет ядру буфер, в который ядро делает memcpy :)

это правда

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

должно, но не обходится. смотрите на реализацию в Go хотябы

это рома прав

только не memcpy оно делает, а mmap

чем мой ответ отличается от этого?

epoll/kqueue/iocp? не вкурсе только о kqueue. кроме обвязки (в сравнении с простой реализацией) все тоже самое чтение, что я описал выше - в recv отправляется указатель на буфер и длина и ядро в пользовательский буфер пишет данные из буфера сокета и возвращает кол-во записанных

на самом деле не так ) пользователь предоставляет ядру буфер, в который ядро делает memcpy :)

Да хрен с ними с сисколами и ядром. Главное, как память-то не выделять на каждое заходящее UDP, но читать его и долго потом думоть?

элементарно. аллоцируем пачку(допустим, 1024 шт) буферов по 2048 байт и пользуемся этим пулом.

http://yusufonlinux.blogspot.ru/2010/11/data-link-access-and-zero-copy.html

я линк не открывал, но скорее всего там говорят про AF_PACKET и packet_mmap

угу там про AF_PACKET

про пачку буфферов я вариант предложил выше, через Sync.pool например

только не memcpy оно делает, а mmap

для большинства сисколлов всё-таки memcpy.

но не для сети

но тут эксперты говорят я не понимаю ничего в сокетах

сетевой буфер можно без единой аллокации, кроме первичной, протащить от входа до выхода

по дороге прямо в нем поменяв соответсвующие поля

но не для сети

увы, для сети тоже. я вчера как раз развлекался с recvmmsg/sendmmsg

ну, хорошо

я вот вчера с ними не развлекался, поэтому спорить не буду

когда я развлекался с ними в последний раз - лишних аллокаций в java nio не было

вообщем, там в топе copy_user_enhanced_fast_string

0,46 │ mov %edx,%ecx 97,27 │ rep movsb %ds:(%rsi),%es:(%rdi) 0,08 │ xor %eax,%eax

и вот как-то так она выглядит в профайлере

вообщем, там в топе copy_user_enhanced_fast_string

в мире Джава все не так, там нет никаких лишних аллокаций

:)

в мире Джава все не так, там нет никаких лишних аллокаций

рукалицо.jpg

да у меня тоже это был сарказм)

вообщем-то у проблем у Михаила Монашева немного

да рази ж дело в михаиле?..

1) в go нет sendmmsg/recvmmsg

зёпа

2) в go нет какого-либо api чтобы переиспользовать буфер

вообщем-то, всё это решаемо

написанием своих велосипедов )

2) в go нет какого-либо api чтобы переиспользовать буфер

какой буфер имеется ввиду?