Perhaps more to the point, how best to run an application like CPRS in
a WAN environment is an interesting problem. Unfortunately, you can't
have everything for free, and a simple request/reply paradigm may not
be the best way to go over a WAN. There are other alternatives, though.
Keep in mind that when the Broker was designed, it was used primarily
over a LAN in a single medical center. Instead of just trying to
directly port applications to a new environment without really looking
at the basic infrastructure, you might be better off thinking about new
communications models.
====
Gregory Woodhouse
[EMAIL PROTECTED]
On May 12, 2005, at 5:25 AM, Gregory Woodhouse wrote:
Do you run the VPN over TCP or UDP? I know that TCP based RPC
protocols (like the one used by the Broker) are still problematic
over a WAN, but this would at least take window size at the VPN level
out of the equation. You can also monitor window size using a tool
like tcpdump.
====
Gregory Woodhouse
[EMAIL PROTECTED]
On May 11, 2005, at 9:23 PM, Cable One wrote:
After reading all of the interesting comments regarding the cause of
the
slow CPRS I would like to throw in my 2 cents worth.
I am not sure that this is a BANDWIDTH problem, but rather a problem
of the
WAN (wide area network) not being designed to handle the kind of
network
traffic that it is being tasked with. I am rather new to Vista and
CPRS, but
I am a bit of an old hand with the design of wans for all sorts of
network
traffic.
The performance of a client-server relation pair is mostly dependant
upon
the sort of network traffic that will travel upon it. Given that we
are
running this on tcp/ip I will focus there. When we speak of
bandwidth, most
of use really mean THROUGHPUT or how much data can I move in some
unit of
time. TCP uses the concept of a window to control the flow of data and
verify that all of the packets get to their destination. This window
is just
the number of packets (or bytes of payload data) that the sender will
send
until it insists upon receiving an acknowledgement from the receiver.
As the
receipt of this ackknowledgement requires a round trip from sender to
receiver to sender, this throughtput can be described as:
T = WINDOW(in bytes) / RTT(round trip time)
The RTT is made up of 3 components:
1. Propagation delay. Set by nature as in the speed of light or
electricity through a wire (60-80% C)
2. Queueing delay. The waiting time in the tcp/ip stacks of
routers,
interfaces, switches etc.
3. Transmission delay. This is the BANDWIDTH. This is the speed
with
which you can load the media. How fast can data be put into the end
of the
wire/optical fiber etc.
The window size is variable, negotiated by the tcp/ip stacks at
either end
of the connection. The propagation delay is mostly out of our
control. The
queueing delay is mostly out of our control. The transmission delay
we can
have some sort of control over bits of it....how fast is my ethernet
connection to the router? how fast is the DSL that I am paying for?
Most of
these parameters are not in our immediate control at all, and can
only be
measured in aggregate with other parameters. We can buy more
bandwidth on
our DSL connection and this will have the effect of lowering the
transmission delay (ie, increasing bandwidth) but this only has a
limited
effect on increasing the throughput of the connection.
This discussion has made the assumption that we are looking at the
steady
state transmission of a data stream. You can see (I hope) that the
throughtput gets exponentially worse with increasing RTT. This REALLY
causes
problems when the nature of the client-sever traffic is not a steady
stream,
but rather a series of short transactions. In a network with highly
variable
RTT and lots of short transactions the transfer of data can be almost
unbearable. Welcome to the world of using Microsoft Access over the
internet
with a VPN. Its performance is terrible.
If CPRS is communicating with lots of short messages, this can make
VPN over
the internet a less than desirable network design. Buying more
bandwidth
will help some, but may not be a cost effective solution in your
case. Given
what was said about the configuration of the network described I
would want
to know more about what else was being done with Internet traffic in
the
remote and local lans, ie how many people are doing streaming audio,
video
etc. I do not think that bandwith monitoring would be of much value.
I would
be more interested in conversation monitoring.....or looking at the
individual tcp data streams between server and client (vista and
CPRS) and
analyzing those in terms of delay times and retransmission requests.
I hope that these ramblings have been of some value. I would be glad
to
deepen this conversation privately or on the phone.
By the way, software firewalls do not use any more bandwidth than
hardware
firewalls. Under the covers they are exactly the same thing.....CPU
running
some program connected to a couple of NICs.
Best regards,
Donald R. Donigan
donigan technology, LLC dba
Desert CODE Works
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
