Rainer: > > One area I am not quite sure about yet is what minimum size > > of messages should implementations be forced to support. It > > definitely can't be the full allowed size of 16MB as some > > hardware won't support it. Right now it is set at 65k, which > > means implementations are forced to support fragmentation. I > > I think this is the most important one. I strongly think that > we should NOT say the max MUST is 65k - if we really do this, > we acutally say that everything beyond 65k can not really be > expected to work. We must guarantee that the max size of 16 > MB can be reliably transmitted, else the whole thing is useless.
I think we need to find some compromise. Requiring 16MB would not be a good idea for cases where implementation runs on systems with less than 16MB of RAM. My compromise suggests that you can send 65K message to any implementation. In very rare cases when your systems is designed to send larger messages, you would need to use specific implementations that support it. > After reading this parts of the draft, I have to admit I am > not sure if it really was a good idea to move the > fragmentation into the transport. As it was designed in > -protocol, it were multi-part message, very low overhead, > very easy to deal with enourmous amounts of data. A key to > that simplicity was that each receiver was free to *ignore* > multi-part messaging, because each multi-part message was a > valid syslog message in itself and could be treated as such - > no complexity at the receiver/relay, nothing that could > overrun a low-end device. Now, we mandate that everybody > support the full sizes ... And begin to get into trouble. I see your point, but I think these are different scenarios. If somebody wants to associate multiple regular syslog messages into one using some structured content tags (including parts or whatever) it is fine. But there are cases when user specifically needs to transmit a big message and, in this case, making the user break it or just receive it as broken into pieces is not user-friendly. I think pushing things like re-assembly on the user is not good. If you deal with reassembly, the other approach is the same in that regard. The only real difference is that the other approach also replicated syslog header in every message. We can do it. This obviously has it is pros and cons. Waste is obviously a disadvantage (space, more parsing during reassembly, more fragmentation because of header overhead, etc). The only advantage is that you could potentially make stateless relay routing decisions without re-assembly by parsing header of every message. I don't believe it is a big deal. Do you? If we are talking about using source IP and source port during re-assembly of messages like the current draft does, I do think that transport layer is the appropriate place for fragmentation. > In any case, however, I strongly suggest that we require that > full message size is supported, because otherwise it is > pointless to mention it. As I said, with the current proposed > ID the max size is actually 65k, which I think is not in the > spirit of -protocol. > > > Re 4.1: > ### > 4.1 Target Port > Syslog receivers MUST support accepting syslog message > datagrams on a well-known UDP port 514. Syslog senders MUST > support sending syslog message datagrams to the UDP port 514. > ## > > Is this really a MUST? Many admins will not allow this, any > real-world syslog deamon must support non-514 ports (only), > because else it will probably be ditched for security reasons > by some admins. It says "MUST support". This means an implementation must be *capable* of doing this. It does not say "MUST accept". So, my wording was meant to imply that it can, indeed, be changed administratively or implementation can listen on multiple ports or whatever. I can wordsmith it to make it clearer. > Re 4.2: > ### > 4.2 Source Port > Syslog senders can use any source UDP port for transmitting > messages. Senders MAY randomly select a source port, but MUST > use the port in an exclusive fashion. No concurrent port > reuse on the same host is allowed. > > ### > I think I can not guarantee "no concurrent port reuse" in our > implementatons - this may be very hard to avoid in > multi-process, multi-threading apps. I suggest we drop this > requirement. I want to understand your issues here better. Can you elaborate? The guarantee of no concurrent use of the same port (or socket) is typically provided by the UDP/IP software stack. Basically, it is the default behavior (you get a random available port assigned) unless you specify a flag to force it behave otherwise (on Unix, SO_REUSEPORT or SO_REUSEADDR). The reason I kind of want this there is that it allows to distinguish sending processes and not confuse fragments from two different processes. > I've seen RFC 3164 being referenced multiple times. AFIK, > this can cause problems in becomeing a standards-track RFC > (because 3164 is informational). Just a hint to check with > those experienced in these issues - I may be totally wrong. I don't think it references it as an authoritative source of anything, more as a historical reference. But I'd be happy to remove references if people think it is important. I kind of wanted to give some context for this standard. Thanks, Anton. > > Rainer >
