Undelivered Mail Returned to Sender

From: Mail Delivery System <MAILER-DAEMON@caucho.com>
Date: Sat Jun 24 2006 - 00:23:21 PDT

This is the Postfix program at host caucho.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                        The Postfix program

<johnm-hessian@xxx.net> (expanded from <hessian-interest-mailout>): delivery
    temporarily suspended: Host or domain name not found. Name service error
    for name=non.net type=MX: Host not found, try again

attached mail follows:


Hello.

On Paul W. Cowan wrote:
> Each message we pass contains multiple elements
> who's value is a single character or number less than 255. It may
> seem insignificant, but the extra overhead of 3 or 4 bytes for each
> int or binary format value becomes significant in volume.

Even without protocol extensions if many small integers are to be sent
in single message they can be well packed into a binary element.

However I think that for cases where even more compact representation
is important a good compromise would be adding a compact integer
format that looks like one used for UTF-8 encloding. See for example
http://en.wikipedia.org/wiki/UTF-8. But int his case we do not need
keep compatibility with ASCII and encoding can be simpler.

It could be something like
'i' nnnddddd dddddddd .... (up to 9 elements)
where 3 bits nnn represent number of bytes in the sequence - 1
and remaining bits ddd... contain bits of required integer.

For example: 0xfff => 00101111 11111111

One reasonable variation here - instead of 3 use 4 bits for length
representation thus covering even those cases that are beyond 'long'
datatype.

I think that extra complexity should be added with extra care. But
this single extension to the protocol can cover many cases and
provides reasonable (but not best of course) compression.

--
Petr Gladkikh
Received on Sat 24 Jun 2006 00:23:21 -0700

This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 20:16:41 PDT