На маишне вертятся равноправные процессы, они как бы постоянно умирают, запускаются новые, но в каждый конкретный момент времени нужна возможность послать N байт, и чтобы все их получили в одинакомо виде. Как можно реализовать?

UNIX SOCKETS.

Vladimir

Ну так если один процесс считает из сокета — другим то разве что останется?

Здравствуйте, Аноним, Вы писали:
А>Ну так если один процесс считает из сокета — другим то разве что останется?

останется, не сумлевайтесь.

Все равно я как то смутно себе представляю картину, будет 200 процессов или более, как тут сокет может помочь? и как тогда данные будут удаляться из потока?

shishkovsky.vladimir wrote:
> UNIX SOCKETS.

Они поддерживают broad/multicast?

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Аноним wrote:

> На маишне вертятся равноправные процессы, они как бы постоянно умирают,
> запускаются новые, но в каждый конкретный момент времени нужна
> возможность послать N байт, и чтобы все их получили в одинакомо виде.
> Как можно реализовать?

udp multicast

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Здравствуйте, Аноним, Вы писали:

А>Все равно я как то смутно себе представляю картину, будет 200 процессов или более, как тут сокет может помочь? и как тогда данные будут удаляться из потока?

У каждого процесса будет свой независимый канал с твоим отправителем данных.

Аноним wrote:
> Все равно я как то смутно себе представляю картину, будет 200 процессов
> или более, как тут сокет может помочь? и как тогда данные будут
> удаляться из потока?

http://www.tldp.org/HOWTO/Multicast-HOWTO-1.html

...
Multicast is much like radio or TV in the sense that only those who have tuned
their receivers (by selecting a particular frequency they are interested on)
receive the information. That is: you hear the channel you are interested in,
but not the others.
...

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Здравствуйте, MaximE, Вы писали:

ME>Аноним wrote:

>> На маишне вертятся равноправные процессы, они как бы постоянно умирают,
>> запускаются новые, но в каждый конкретный момент времени нужна
>> возможность послать N байт, и чтобы все их получили в одинакомо виде.
>> Как можно реализовать?

ME>udp multicast

Я сильно сомневаюсь, что он будет работать в пределах одного хоста.

Вообще похоже, что тут самый правильный путь — через каталог на диске и пакеты в нём файлами. Для эффективности сделать соответствующее место RAM-диском

netch80 wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Аноним wrote:
>
>> > На маишне вертятся равноправные процессы, они как бы постоянно умирают,
>> > запускаются новые, но в каждый конкретный момент времени нужна
>> > возможность послать N байт, и чтобы все их получили в одинакомо виде.
>> > Как можно реализовать?
>
> ME>udp multicast
>
> Я сильно сомневаюсь, что он будет работать в пределах одного хоста.

ip-протоколу физическое местоположение хоста не имеет значения.

Чтобы получать малтикасты с той же машины, с которой они отправлены, нужно не
забыть две веши.

1) для отправителя включить опцию:

IP_MULTICAST_LOOP
Sets or reads a boolean integer argument whether sent multicast
packets should be looped back to the local sockets.

2) для получателя присоединиться к группе и на локальном интерфейсе:

int mk_udp_mc_listener(ip4_addr addr)
{
     int s = socket(PF_INET, SOCK_DGRAM, 0);
     if(-1 == s)
         throw std::runtime_error("socket");

     nonblocking(s);

     int buf_size = 1 * 1024 * 1024;
     if(setsockopt(s, SOL_SOCKET, SO_RCVBUF, &buf_size, sizeof buf_size))
         LOG_WARN(ludp, "setsockopt(SO_RCVBUF) failed"); // not vital

     int so_reuseaddr_val = ~0;
     if(setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &so_reuseaddr_val, 
sizeof(so_reuseaddr_val)))
         throw std::runtime_error("setsockopt");

     sockaddr_in sa(mk_sockaddr_in(addr));
     if(bind(s, (struct sockaddr*)&sa, sizeof(sa)))
         throw std::runtime_error("bind");

     struct ip_mreq m;

     m.imr_multiaddr = sa.sin_addr;

    m.imr_interface.s_addr = htonl(INADDR_LOOPBACK);
     if(setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &m, sizeof(m)))
         throw std::runtime_error("setsockopt");

     m.imr_interface.s_addr = htonl(INADDR_ANY);
     if(setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &m, sizeof(m)))
         throw std::runtime_error("setsockopt");

     return s;
}

--
Maxim Yegorushkin

netch80 wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Аноним wrote:
>
>> > На маишне вертятся равноправные процессы, они как бы постоянно умирают,
>> > запускаются новые, но в каждый конкретный момент времени нужна
>> > возможность послать N байт, и чтобы все их получили в одинакомо виде.
>> > Как можно реализовать?
>
> ME>udp multicast
>
> Я сильно сомневаюсь, что он будет работать в пределах одного хоста.
>
> Вообще похоже, что тут самый правильный путь — через каталог на диске и
> пакеты в нём файлами. Для эффективности сделать соответствующее место
> RAM-диском

Хороший способ. Но когда ты будешь удалять эти файлы?

С малтикастом проще: не нужно думать об именах файлов, не нужно думать, когда их
нужно удалять. Каждый процесс, который присоединяется к малтикаст группе будет
получать копию дейтаграммы.

Или я что-то упускаю и файлы здесь лучше?

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Я уж было думал опуститься до снифера, но рута не хотелось юзать. Раз есть такая клевая штука — это ко мне.
Пошел разбираться

Спасибо!!!!

Ты не понял задачу, нет единого отправителя, есть как бы общий котел, куда все процессы кидают посылки, и все же их получают, т.е. один послал — 200 получили, второй послал — 200 получили.

Здравствуйте, Аноним, Вы писали:

А>На маишне вертятся равноправные процессы, они как бы постоянно умирают, запускаются новые, но в каждый конкретный момент времени нужна возможность послать N байт, и чтобы все их получили в одинакомо виде. Как можно реализовать?

Конечно, зависит от характера данных, но как еще вариант — shared memory ?

Аноним wrote:

> А>На маишне вертятся равноправные процессы, они как бы постоянно
> умирают, запускаются новые, но в каждый конкретный момент времени нужна
> возможность послать N байт, и чтобы все их получили в одинакомо виде.
> Как можно реализовать?
>
> Конечно, зависит от характера данных, но как еще вариант — shared memory ?

shared memory — это всегда самое производительное решение
Может быть несколько более не тривиальное, чем multicast. т.к. придется
реализовать очень похожую функциональнось, что уже реализована в ядре.

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Здравствуйте, MaximE, Вы писали:

ME>Аноним wrote:

>> А>На маишне вертятся равноправные процессы, они как бы постоянно
>> умирают, запускаются новые, но в каждый конкретный момент времени нужна
>> возможность послать N байт, и чтобы все их получили в одинакомо виде.
>> Как можно реализовать?
>>
>> Конечно, зависит от характера данных, но как еще вариант — shared memory ?

ME>shared memory — это всегда самое производительное решение
ME>Может быть несколько более не тривиальное, чем multicast. т.к. придется
ME>реализовать очень похожую функциональнось, что уже реализована в ядре.

Если только данные не сколько нибудь приватны.Тогда конечно, броадкаст по UDP нельзя использовать.
И тоже — смотря про какую память мы говорим: SysV или POSIX.
Вызов mmap, например, может быть достаточно затратным.

ME>--
ME>[i]Maxim Yegorushkin

Vladimir D Belousov wrote:

> Здравствуйте, MaximE, Вы писали:
>
> ME>Аноним wrote:
>
>> > А>На маишне вертятся равноправные процессы, они как бы постоянно
>> > умирают, запускаются новые, но в каждый конкретный момент времени нужна
>> > возможность послать N байт, и чтобы все их получили в одинакомо виде.
>> > Как можно реализовать?
>> >
>> > Конечно, зависит от характера данных, но как еще вариант — shared
> memory ?
>
> ME>shared memory — это всегда самое производительное решение
> ME>Может быть несколько более не тривиальное, чем multicast. т.к. придется
> ME>реализовать очень похожую функциональнось, что уже реализована в ядре.
>
> Если только данные не сколько нибудь приватны.Тогда конечно, броадкаст
> по UDP нельзя использовать.

Криптография не поможет?

> И тоже — смотря про какую память мы говорим: SysV или POSIX.

Мне интересно, в чем разница?

> Вызов mmap, например, может быть достаточно затратным.

На какой платформе и при каких условиях? Какие альтернативы?

На Linux, к примеру, mmap всего лишь создает еще одну vm_area_struct
http://www.linux-m32r.org/lxr/http/source/include/linux/mm.h#L58 . Страницы же
отображаются при первом доступе.

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Здравствуйте, MaximE, Вы писали:

ME>Vladimir D Belousov wrote:

>> Если только данные не сколько нибудь приватны.Тогда конечно, броадкаст
>> по UDP нельзя использовать.

ME>Криптография не поможет?

Конечно поможет. Но я и, и Вы сможем привести кучу примеров, когда это будет выгодно или не выгодно по разным причинам.

>> И тоже — смотря про какую память мы говорим: SysV или POSIX.

ME>Мне интересно, в чем разница?

Очевидно, в самом принципе работы и интерфейсе.
Где-то может быть потребуется рядом с каждым сообщением mutex или семафор поставить.

>> Вызов mmap, например, может быть достаточно затратным.

ME>На какой платформе и при каких условиях? Какие альтернативы?

ME>На Linux, к примеру, mmap всего лишь создает еще одну vm_area_struct
ME>http://www.linux-m32r.org/lxr/http/source/include/linux/mm.h#L58 . Страницы же
ME>отображаются при первом доступе.

А отображается сразу весь файл, или по мере возникновения страничных отказов?
Ведь допустим, у нас 100 процессов, которые хаотично (или последовательно) вызывают mmap и munmap.
Не заколебется ли ядро загружать/выгружать страницы, читать/записывать файл (я просто не знаю)?
В случае с SysV памятью это как-то более красиво получается, хотя я вполне могу ошибаться.