coonasty
asked on
having problems with peachtree over vpn connection.
have peachtree accounting 2010 version. vpn works fine and can get into peachtree server share data folder perfectly fine from remote client. however when i open peachtree on remote client it opens fine, but when i try to open a company from within peachtree from the server it freezes up peachtree and gives a "not responding" in task manager.
PeachTree uses the Pervasive PSQL database, but it uses it in such a way that relies on a lot of round-trip packets going back and forth. For example, each database request to read a record must be sent to the server, then the server responds with that request. In a normal LAN configuration, this round-trip time is very small -- with database response time of usually less than 0.1ms. Thus, if you read 1000 records for a given operation, it takes 1/10th of a second -- nice and fast.
However, when you run this same application over a VPN, you have each packet stopping at the VPN client to be encrypted, then sent over the high-latency link, then decrypted on the server side. The server response is still 0.1ms (or better), but then the reply has to be encrypted, sent across the link, get decrypted, and then received by the app. Try PINGing the server and see what your round-trip latency time really is for all of the devices in-line. If you are seeing latency around 20ms (which is usually pretty good for a VPN link), then a bit of quick math will tell you that this will be running about 200x slower than normal, and what takes 0.1 second on the LAN will take 20 seconds.
If packets are being dropped from the link, then the time delay increases 10-fold or more. The TCP stack only retransmits after about a 250ms delay for a lost packet -- and during this time, the application is really "not responding", since it is waiting for the server and network to reply. (BTW, all "not responding" means is that the application is not listening to its Windows Message queue, and doesn't really indicate that the application is hung.)
My recommendation for running ANY client/server application (database apps included) is to use remote desktop, Citrix, or some other sort of remote control solution. In this way, the round-trips are kept local to the server environment, and the screen-shots are sent across the wire, where latency is less of an issue (since screen-shorts are mostly one-way transfers that can be streamed and utilize higher available bandwidth).
To verify this, try giving it a few minutes and see if it eventually finishes. While you're doing this, have someone watch the server from the Pervasive Monitor application and see if the network packets continue to increase while you are waiting. My bet is that they are.
However, when you run this same application over a VPN, you have each packet stopping at the VPN client to be encrypted, then sent over the high-latency link, then decrypted on the server side. The server response is still 0.1ms (or better), but then the reply has to be encrypted, sent across the link, get decrypted, and then received by the app. Try PINGing the server and see what your round-trip latency time really is for all of the devices in-line. If you are seeing latency around 20ms (which is usually pretty good for a VPN link), then a bit of quick math will tell you that this will be running about 200x slower than normal, and what takes 0.1 second on the LAN will take 20 seconds.
If packets are being dropped from the link, then the time delay increases 10-fold or more. The TCP stack only retransmits after about a 250ms delay for a lost packet -- and during this time, the application is really "not responding", since it is waiting for the server and network to reply. (BTW, all "not responding" means is that the application is not listening to its Windows Message queue, and doesn't really indicate that the application is hung.)
My recommendation for running ANY client/server application (database apps included) is to use remote desktop, Citrix, or some other sort of remote control solution. In this way, the round-trips are kept local to the server environment, and the screen-shots are sent across the wire, where latency is less of an issue (since screen-shorts are mostly one-way transfers that can be streamed and utilize higher available bandwidth).
To verify this, try giving it a few minutes and see if it eventually finishes. While you're doing this, have someone watch the server from the Pervasive Monitor application and see if the network packets continue to increase while you are waiting. My bet is that they are.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
what are the tricks that you used to make it work? i am trying to use 2 sonicwalls and peachtree 2013. help
couple of questions here. Are these databases large? If so, there are MTU consideration issues here which can be tweaked if necessary both on vpn server and remote client. The freezing might be occuring due to fragmentation issues of the database packets. Can you reach the peachtree server database shared folder by hostname? If the application is hard coded to reach this by hostname and not ip address, this would cause freezing and a hostfile entry on the client with the server hostname to ip mapping might resolve this. Otherwise, please post size of these database files and we will consider adjusting mtu on client first, then possibly something called MSS (maximum segment size of tcp packets) on firewall/vpn server.
thanks