Gee Ed, what happened. There was almost an hour difference from when the message was posted till when you answered. I thought you had ESP and knew when a message was posted here that described a problem where a Network Moron was pointed at the application???

Well, at least you're here to give correct technical descriptions of the problem in a printable format that we can give to said moron and watch his demeanor change rapidly.

Thanks,

PF

>>Hi everyone,
>>
>>We've just installed a Visual Foxpro product on a WINNT machine, running on a Novell network. The person using the server has really good response time - however anyone using the network (we've simply shared access to the tables to allow multi-user) has a problem with response time.
>>
>>According to the customers network "Guru" (I think he wrote "War & Peace" too):
>>
>>"the problems experienced by the product when run from a networked machine appear to be caused by the products' utilisation of the NBT protocol. NBT (NetBios over TCP/IP), is a fairly simple protocol, that propagates network broadcast packets when invoked. When a user connects to network share offered by the server, this opens
>>a NBT connection to the server. This NBT connection appears to be the limiting factor when a process is initiated in that server via the workstation. When monitoring the NBT connection to the server, the effect of initiating a Fueltrac process is an immediate increase of NBT traffic between the two machines to 100%. This suggests that the neither the server, or the workstation (client), are the limiting factor responsible for the massive increases in response time
>>from the server, rather that the NBT traffic is. To test this, the server and local workstation were monitored for processor activity and memory activity during the process of report generation, and neither machine showed signs of stress, however NBT traffic rose to 100% immediately. As a test NBT was disabled on the server (and workstation), and an attempt to generate a report was made. This attempt was unsuccessful. This suggests that the software itself dictates that the NBT protocol should be utilised. The server and workstation were capable of using alternative protocols, but none
>>were used.
>>
>
>He's blowing smoke - to summarize this, he thinks its a problem using the NBT protocol to make the connection between the NT Server and the workstations. He thinks the app is forcing the traffic between the workstation and server to rise dramatically. Duh.
>
>Poor demented individual doesn't understand that the app itself has nothing to do with the selection of protocol. It's dictated by the available network protocols for the workstation and server. Other protocols are available, and can be selected and optimized for the environment. Since you're already running NetWare at the site, it might make sense to drop the TCP/IP protocol entirely in favor of NetBIOS over IPX/SPX. The app has nothing to do with the selection of protocol; iut will use the first available NetBIOS comaptible service in this case to talk to the NT Server; you can change the order of preference and presentation of NetBIUOS layers at both the Server (by changing the priority of the protocols on the protocol stack in the Network Control Panel applet) or at the workstation (by deisgnating which protocol should be used as the default protocol.) VFP relies on the NetBIOS mechanism if its available - it's his responsibility to make sure that his environment negotiates
>the proper setup.
>
>IOW, VFP uses NetBIOS-style netowrking, and uses whatever protocol is available to it for doing NetBIOS, based on the connection between the netowrk client and the server well in advance of the app stepping up to the plate.
>
>>In addition to this problem, the test also showed that the product creates and maintains a network connection to the server during report generation, and that this connection was subjected to a significant degree of stress during this period. This connection may well be unnecessary itself, and needs to be investigated and justified.
>>
>
>Gee, I guess that means that it's moving lots of stuff across the wire. Again, duh. VFP, like any other data-centric system that deals with fileserver-hosted files as opposed to working with a database server that minimizes network traffic by handling much of the manipulation task at the server will generally have this behavior - the faster the data engine and the larger the set of data, the more stuff will tend to be passed over the wire.
>
>I'd suggest a virtual Valium for the file server to reduce its stress, and a heavy dosage of clue-enriched education for the network guru. As to not needing to maintain the connection to the server, well, if you drop the connection, the next time you have to access the file, you'll have to reestablish the connection, and reestablishing the connection and opening the file are the most time-expensive operations done by the application. Adding some memory to the server may help if he's finding excessive paging to be caused by the heavier network traffic.
>
>>This poses problems for the network utilisation of this product, Without true network usability, this product loses worth. The product in its current form does not offer true functionality over a network, due to the unnecessary network connections held open for network clients, and also for the heavy use of those connections. These issues need to be raised, and resolved, with the products'
>>vendors before 'signing off' on the product."
>>
>
>The alternative is to rewrite it with a backend to minimize the amount of data passed over the wire. Doable if this is a real requirement; they just have to shell out the bucks for an appropriate backend, added server capacity, etc. You may be able to reduce network traffic by ensuring that the apps temporary files go to the local drive, and by installing the app locally rather than relying on a copy at the file server.
>
>I'd suggest contacting someone in your area with better understanding of networking and fileserver-based data-centric application behavior and getting them to handle the detailed reply to his critique.