OK, so a while back we decided that it would be a good idea for requests to contain headers that can be mapped to the headers of the underlying protocol.
Now that I'm actually implementing said protocols (HTTP at the moment), it's becoming clear that there is *no* reason to impose a 1:1 correspondence between Remoting requests and requests within the underlying protocol; in fact there are many reasons not to (at least within HTTP).
First of all, due to the relatively high overhead of HTTP, it is much more effective to send multiple messages in one request or reply; especially since messages may be quite small individually. This of course is impossible if a single Remoting request demands a single HTTP request.
Second, not all Remoting messages correspond to requests. Many messages, such as stream data, or service location messages, can vary in size and frequency as well.
Third, in the presence of any protocol in which there are multiple possible channels operating in parallel, it is harder to maintain ordering constraints (in other words, guarantee that message B is processed after message A) when every message must be sent separately, possibly over different connections. When a series of messages are all sent together in a single request, ordering is guaranteed for that group of messages, which will greatly improve latency.
Fourth, the actual payload of a Remoting message is a black-box to users. The user cannot reliably perform any higher-level routing or other message manipulation on a finer level than a per session basis anyway. So there's no real benefit to putting extra data outside of the Remoting request itself.
Comments?
