On Thu, 27 Feb 2003, jfcm wrote:
At 05:30 25/02/03, Alex Rousskov wrote:
On Wed, 26 Feb 2003, jfcm wrote:
No. The question was about parallel command pipe or not. My response
was to try to see if we can have a consistent response. Obviously
triggering a command should probably go the same way as aborting it.
If I understand the above, that is what the current predraft proposal
does. Triggering transaction processing on the other end uses the same
mechanism as aborting that processing (an OPES message with the
corresponding transaction ID xid).
Yes. And this is what I underlined in asking that command and
abort be on the same pipe.
The location of the message (i.e., the connection it is received on)
is a different story. To make aborts efficient, you may want to send
an abort message on a separate pipe that is not clogged with data
messages waiting to be processed (or to be discarded, actually).
This is the issue. You can either think of a spare connection or of
a command connection. When you establish a relation between servers
you may decide that conenction 0 will be the command pipe. I do
prefer that approach as this is a good pipe to signal the sever is
still up and running. Also, in my prefered wording, I would say that
connection 0 would go to the service administrator.
I think we can have a more general/flexible scheme that still allows
what you want: I would like OPES dispatcher to be able to give
connections (and possibly transactions/messages) optional priority. If
the callout server honors the priority setting, then we can have
high-priority "control" connection, for example. If the callout server
does not honor the priority setting or if there is no setting, then
all connections SHOULD be treated with the same priority. In the
latter case, a "control" connection is still possible to establish and
may still be "faster" if it has fewer messages.
It is relatively easy for modern implementations that manage multiple
connections to support rough connection priorities. It usually boils
down to polling a subset of all opened connections more often. Thus,
this optional and simple optimization is likely to be supported by
implementations that care about performance.
As an additional optimization, we could make it possible for either
side to establish a connection that only that side can send on. This
optimization will take care of the situations where a callout server
pollutes high-priority connection with statistics or other unimportant
messages.
It would be good to have a way for one side to reach the other side as
fast as possible, as long as both sides play by the rules. The
difficulty here is that the callout server is not allowed to open its
own connections and, hence, is at the dispatcher will as far as
connection optimization is concerned.
Even under TCP/IP you transport data in blocks/messages (IMHO due to
TCP/IP there could be interest in multiplexed datagrams to go faster
and get easier acks). This means that the non yet used data are in
buffers and will be then processed. When I say swallowing I mean
that the buffers are cleaned (and that the current processes are
signaled to die). I cannot signal processes but I can clean the I/O
buffers (and on the path buffers as the processes can be
multi/machines).
Clearing unprocessed (by application) TCP buffers might be possible
under a very limited set of conditions. For example, the buffers must
be known to contain no useful messages and no partial messages. The
application must have access to pretty low-level TCP controls. Also,
simply handling/keeping TCP packets is already a significant
performance hit and resource drain; discarding them without
application-level processing does not return back wasted CPU cycles.
Finally, TCP-level fiddling is possible if OPES protocol is
implemented directly on top of TCP, but may not be possible for
higher-level bindings.
Please recall that some processes can be quite CPU
consuming. Just ignoring the next protocol message
may result in a lot of unecessary finishing processing.
True. I do not think it is avoidable under general assumptions though.
See above. This is the price to pay for reliable message transmission
and other nice TCP properties. Fortunately, aborts should not happen
often. We optimize the common case, which is the right thing to do.
If you have a TCP/IP pipe you can use it as tansport for an higher
level block transport protocol and design a extremely fast, reliable
and secure value added virtual circuit switch solution. Please
remember that we are in very well defined closed network. Please
review my corrected draft.
I kept dispatcher/services/ends blocks as equal because the command
pipe issue has not been decided. But, let assume that the ONES
system is built only of dispatchers and ends (and may be the ends
also with a dispatcher). This means that the "dispatcher" is acting
as a real time agent (like in X.400/e-mail but real time).
The architecture for a virtual server would then be:
----> dispatcher -----> service admin
|----> service A occurence 1
|----> service A occurence 2
|----> service B occurence 1
|----> service B occurence 2
|----> service B occurence 3
| etc.
And that would be very near from the architecture I
introduced in my first mail about my prototype.
And that is how OPES processor and callout server may be implemented!
A callout server may have an "admin" module that receives all messages
and directs them to appropriate services, doing load balancing if
desired.
The inter-dispatcher protocol could be one of the
services and support soap, etc. under straight
TCP/IP or your OCP under a TCP/IP+ multiplexed
datagram solution with a behaviour and a response
time much closer of a message passing OS.
This could provide a very broad set of consistent
solutions?
Since "this" is actually how OPES may be implemented, I am glad you
think that it could provide a very broad set of consistent solutions.
I doubt the benefits of transaction resumption outweigh increased
protocol complexity. It seems to me that for application protocols we
know about (HTTP and SMTP), an application transaction abort or an
automated retry would be more appropriate solutions. Do you think OPES
transactions should be resumable if the transport layer fails?
Let be clear. I discuss here what I name ONES of which I think OPES
is a fist level. I certainly do not think that HTTP simple systems
to replace a string in a page to correct an URL or to change a .jpg
into a .gif needs that.
But I think that an OPES may come to a point they have to behave as
a ONES because of the load or of the speed. My site does not need
much, but Amazone yes (we have not discussed services running in
parallel and the data to keep from page to page to support a User
cession?).
You have to be more specific for me to follow your logic. What is it
exactly that Amazon needs and that OPES lacks?
Then SOAP is useless. In talking about ONES, we know which
environement we might want to stay consistent with. Also I do not
see here a clear boarder defined yet.
I am not sure about SOAP, but the lack of clear boarder may be
attributed to the lack of understanding what ONES is. So far, I have
only seen abstract drawings that seem to match OPES architecture
pretty well. Perhaps it is just me, but I still do not know what ONES
is and how it is different from OPES.
Also, we may find that a more global vision may simlify and make
more robust the OPES. Or extend the field of their immediate
applictations.
I agree. That is why I am trying hard to understand what ONES is and
what it has that OPES lacks.
Example. I wish to have a new vision of the DNS. I send calls/mails
using domain names and a 0.0.0.0 IP address that an OPES will
replace with the proper current IP of the DN savnig a lot of time:
no more first erroneous resolution and further redirect. And a lot
of flexibility in addressing.
Now we are getting somewhere. An example! However, I am not sure I
fully understand the example: When I send e-mails, I use domain names,
not IP addresses. The name resolution happens when it is necessary to
find a mail handler for the named host. I am not sure how that can be
avoided. Can you clarify how the "new DNS" would differ from the
current one? How OPES would be better at resolving domain names than
current gethostbyname() system calls?
... But I prefer the word "dispatcher" from the dratf. Because it is
more generic and services are processed outside of the dispatcher.
You are right. Most references to OPES processor in the current
protocol predraft should be replaced with OPES dispatcher, I guess.
The proposed protocol handles at least two flows per
application transaction and should scale well with the number of
flows.
Yes. Except that these two flows can be encapsulated into a value
added transport protocol for speed and flow management. That way you
may have cheap and even virtual acks or service messages.
Please remember that we are real time. We cannot make users wait
because another user has big data to process. We must permit to
optimise dispatcher and services CPU time. This certainly means
priority assignement in transmitting data under the protocol.
Maximum flexibility can only come from a service admin talking with
the remote dispatcher. The dispatcher must then act both as a link
and as transport dispatcher.
See above for a proposal on how to add priorities to OPES connections
(and, hence, possibly enable QoS discrimination you are talking
about). I hope it addresses your needs. If not, please specify what
"real time" needs are not addressed by the current scheme and the
above priority proposal.
Thank you,
Alex.