> In the current protocol, fields of all types are represented the > same. They are an arbitrary number of bytes terminated with a newline.
Actually, it's an arbitrary number of bytes in the range 0x20..0xFF encoded in UTF-8, representing a Unicode string with code points in the range 0x0020...0xFFFF. > In a binary protocol you could save a lot of space by representing the 160 > bit key hash as 20 bytes whereas in the current protocol it's a 40 byte > hex string. Space is almost certainly a non-issue. Conversion time is more of an issue for a simulator than a real server, because it isn't network I/O bound. But even if you could build such a simulator, it wouldn't be a very good one because it wouldn't actually be simulating the way real servers use the real protocol. If a badly formed string in the header fields might cause a problem, we should be able to simulate that too. The first rule of solid code is that debug code should be as close to the real thing as possible. Making a simulator different from what it is trying to simulate is just asking for trouble. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
