So we talked about marshalling, data copying, and content
switches, and the fourth component that adds to the latency
of the RPC transmission is protocol processing, and that's
the next thing that we're going to look at. Now the
question is, what transport should we use for the
RPC? And this is where we want to see how
we can take advantage of what the hardware is
giving us. If we are working in a local area
network, the local area network is reliable, and therefore
our focus should really be on reducing the latency
and not worry so much about reliability. It is
often the case that performance and reliability are at
odds with each other. If you focus on reliability,
then performance may take a back seat. So here,
since the RPC performance is the most critical thing
that we are worried about, we're going to focus on reducing
the latency. And we're going to assume that the
LAN is reliable and therefore let's not worry about
the reliability of message transmission in a local
area network. That's the idea behind, the next thing
that we're going to look at. Let's think about
all the thing that could go wrong in message
transmission, and see why some of those things may
not be that important, given that we have a
reliable local area network. The first thing is, you
send a message, it might get lost. But, if in
a local area network, the chances that messages will
actually get lost, is not very high. It happens in
wide area internet, because messages have, have to go
out through several different routers, and they maybe queuing in
the routers, and there may be loss of packets in
the wire and so on. But that's not something that
you have to worry about in a local area
network. So that assumption that messages may not get lost,
suggests that there's no need for low level acknowledgements. Why?
Because you're sending a call and the call is going to
be executed and the result is going to come back. And
usually in network transmission, we send acknowledgements to say that,
yes, I received the message. Now, in this case because
the semantics of RPC says that the act of receiving
the RPC call is going to result in server procedure
execution and the result is going to come back, the result
itself serves as the ACK. And therefore we don't need
low level ACKs to say, oh, I received you arguments
of the call. You don't have to do that. And
similarly, you don't have to have a low level ACK
that says oh, I received the results. Because the results
were not received, the caller, the client is going to resend
the client call. So the high level semantic of RPC can itself serve as a way
we can coordinate between the client and the
server and we can eliminate low level ACKs and
if we eliminate low level ACKs, that reduces
a latency in the transport. The second thing is
in message transmission on the Internet, we worry
about messages getting corrupted. Not maliciously or anything like
that, but just due to vagaries of the
network messages may get corrupted in going on the
wire that connects the source and destination. And
for that reason, it's typical to employ checksum in
the messages to indicate the integrity of the
message that checksum is usually computed in software and
appended to the message and sent on wire.
But in a local area network things are reliable,
we don't have to do extra overhead and
software for generating the checksum, just use hardware
checksum if it is available, just use hardware
checksum for packet integrity. Don't worry about adding an
extra layer of software in the protocol processing
for doing software checksum. So that's the second optimization
that you can make to make the protocol
processing leaner. The third source of overhead that comes
about in message transmission is once again related to the fact that
messages may get lost in transmission. And therefore in order to make sure
that if messages are lost in transmission, you usually buffer the packets. So
that if the message is lost in transmission, you can re-transmit the package.