pproxy pprc5in.rc5 ?

[RC]

Does the pproxy proggie issue the blocks within pprc5in.rc5 in a FIFO (First In First Out) fashion?

Edit: What if a client requests large block size (33)? Does the keyserver still maintain a FIFO algorithm?

 

[Kilowatt]

<< FIFO fashion >>

What's that?
Yes the RC5 inbuffer is named pprc5in.rc5
The OGR inbuff is named ppogrin.ogr
The out buffers are so named pprc5out.rc5 and ppogrout.ogr

 

[Russ]

FIFO is First In First Out. Don't know the answer to that myself.

Russ, NCNE

 

[JHutch]

The proxy is FIFO. However, when a client requests a different size block than the next available, the proxy will do a quick search of about the next 32 (I think) blocks, to see if any match. Older proxies used to search a much larger section of the keyspace they had, looking for a size match, but people were seeing a significant performance hit on their machines, so that function was pared down.

JHutch

 

[RC]

JHutch: Your description conflicts with your statement that the keyserver functions in a FIFO fashion. If the next block in the FIFO queue is skipped because the client requested a large block then how is the keyserver supporting a strict FIFO algorithm?

I vaguely remember a thread in which someone described the fact that after a keyserver has been running for a while that the remaining blocks tend to all be small blocks if the clients have been requesting large blocks. The person that posted this may have been under the wrong assumption.

I would hope a description of how the keyservers/pproxies function in this regard would be on the dnet site, but I've never seen such an article on dnet.

In everyday use the issue probably isn't of much importance.

 

[JHutch]

OK, I'll try to make it a little clearer...

The proxy is FIFO as long as the client is requesting the same size block as the next block in line.

Suppose my pproxy is holding the following size keys...

8
16
12
4
32

Now, suppose a client connects and asks for a size 32 block. The proxy is going to look down through its block list. It will skip the first 4 blocks and grab the 32 size block. But, then say a client connects and asks for a size 8 block. It will grab the first size 8 block it can find.

To speed up the proxy, it only looks at about the first 32 WU in its keyspace. If it searched the entire list it has for every request, it could ridiculously slow down the proxy.

Also, if someone requests a size 8 for instance, and only size 16 and bigger are available, the pproxy will &quot;chop&quot; a bigger unit into multiple smaller units and send one of the smaller units. That is how defragmentation happens and why sometimes the key servers only seem to have little tiny blocks.

So, in conclusion, the pproxy is FIFO, but it a modified FIFO. It adds a little intelligence to try and match the unit size to what was requested...

I hope this makes it a little clearer,
JHutch

 

[RC]

Your original description was sufficient. I had trouble with the concept of an algorithm that supports a FIFO queue and does not support it.

On a more important note, let me congratulate you 🙂
I see from your profile that your one year anniversary is Oct. 11.

I imagine you have seen a lot of changes during the last year.