netdev - Re: Add PGM protocol support to the IP stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1003221300180.17230@router.home>
Date:	Mon, 22 Mar 2010 13:07:37 -0500 (CDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Add PGM protocol support to the IP stack

On Mon, 22 Mar 2010, Andi Kleen wrote:

> > What I have right now is:
> >
> > 1. Opening a socket
>
> >
> >         A. Native PGM
> >
> >                 fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
>
> RDM = Reliable ? Multicast ?

RDM is Reliable Datagram Multicast I believe. I'd rather have SOCK_PGM if
I could choose.

>
> >         B. PGM over UDP
> >
> >                 fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
> >
> >         C. PGM over SHM (?)
> >
> >                 fd = socket(AF_UNIX, SOCK_RDM, 0)
>
> Not sure how that should work.

Multiple processes would communicate via shm segments. Maybe defer to the
future but its an important operation mode as the systems grow bigger and bigger.
SHM segment would have to contain some sort of ring buffer that the
receivers could tap into. But that mode has not really been thought
through.

> > 3. Sending and receiving
> >
> >         Use the usual socket read and write operations and the various flavors of waiting
> >         for a packet via select, poll, epoll etc.
> >
> >         Packet sizes are determined by the number of  packets in a single sendmsg() unless
>
> Number of bytes surely?

Sorry yes you are right.

> >         overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
>
> That's unusual to have such a option (except the MTU). What is it good for?

No idea why it was implemented. It can be used to use send() for portions
of a message. Triggers the send() only when all bytes have been provided.
Probably necessary if one wants to have very long (megabytes) messages.
Esoteric and likely not going to be in a first release.

> > 4.      Transmitter Socket Options
> >
> >
> >         A. Setting the window size / rate.
> >
> >                 struct pgm_send_window x;
> >                 x.RateKbitsPerSec = 56;
> >                 x.WindowSizeInMsecs = 60000;
> >                 x.WindowSizeinBytes = 10000000;
> >
> >                 setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
> >
> >                 Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
>
> That's a very large buffer for a socket. It would be better to use the usual
> auto shrinking/increasing mechanisms.

Reliable multicast protocols have a defined time period / "reliabilty
buffer" so that they can resend a message that was missed for a time
period. It is customary to either specify a time period or define the size
of the "reliability buffer".

> >         B. FEC mode
> >
> >                 struct pgm_fec_info x;
> >
> >                 x.FECBlocksize = 255;
> >                 x.FECProActivePackets = 0;
> >                 x.FECGroupSize = 0;
> >                 x.fFECOnDemandParityEnabled = 1;
> >
> >                 setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
>
> Is that mode really needed?

Never used it. I'd rather skip for now. Maybe later.

>
> > /* Socket API structures (established by M$DN) */
> > struct pgm_receiver_stats {
> >         u64     NumODataPacketsReceived;        /* Number of ODATA (original) sequences */
>
> It's difficult to maintain 64 bit counters on 32bit hosts on all targets.
> But I guess it would be ok to only fill in 32bit in this case.

32 bit counters have the awful habit of overflowing.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html