I had a think about structured replies over the weekend. The current proposal is a big change for any existing server implementation (and, I suspect, client implementation).
One thing that struck me is that each chunk of the reply is sort of handled like a reply of its own. The simplest way for me to code them was probably to break up each request into internal sub-requests, have each of those fire off in parallel, send their own replies, and send a final segment once all had been sent. At this point, the following occurred to me. If I knew the client would respect my maximum blocksize, I could achieve about 90% of what structured replies do simply by setting a maximum blocksize. The client would break up each request into a suitable size chunks, and would send them all back independently. I'd not need to chunk anything. The main thing I'd be missing from structured replies would be the ability to put an error code at the END of a read (that currently prevents sendfile type implementations of read as you need to know whether the read fails anywhere before you start sending the beginning). Is the current structured-reply extension incredibly baroque for no gain? Could we do something much simpler if we assume that the 'chunking' is done by the BLOCKSIZE stuff? -- Alex Bligh ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
