Re: Basic Network Practice?
Client/Server applications imply 2 applications 1 which acts as a server and another which acts as a client. Typically the Client connects to the server and then sends or requests data from the server app and the server responds as needed.
VB supports UNC paths so it is possible to talk to a database that is on a shared network drive or folder without it being mapped
\\Server\ShareName\PathFilename
One issue with using a mapped drive is that all workstations have to map it to the same drive letter and must make sure it is connected. UNC path is a bit more flexible
Yes you can use Winsock to create a client server pair of applications but if you are dealing with a db on a shared resource of the local lan then not normally needed.
Re: Basic Network Practice?
You don't really have what anyone would call a client-server application. You have a monolithic application where multiple instances are sharing files on a common file server. For the purposes of application architecture a file server is not a server, just a shared directory.
Most actual client-server applications require a separate machine dedicated to running server applications. The main reason is that a PC might be shut off when some user needs the application, but another is that many people write desktop software in such a way that they eat excessive resources assuming they "own" the entire machine.
See the tons of silly examples of file I/O here that suck entire files into RAM then turn around and split that into an array of lines, etc. Poor practice even for a desktop app but it's a common script kiddie hack use by entry level plinkers. Since the days when RAM began to be measured in 100s of MB and even GBs they get away with it more easily and the abuse has ramped up accordingly.
The degenerate case of a client-server application is when you use a "client-server database" e.g. SQL Server. There you offload the data tier of your application to the server while still getting away with monolithic coding techniques... up to a point. But you also gain in database integrity: if a client PC crashes it becomes much less likely your database will be corrupted.
However large scale applications often need to graduate to "n-tier" techniques where more of the business logic runs at the server with a data tier behind that (possibly on a separate server) and the client code becomes smaller. The extreme case of this is when your client is something generic such as a terminal or Web browser, where little or no local computing takes place. This can be far more scaleable and secure since the raw data stays back on the server farm and the client has no direct access to the database.
Re: Basic Network Practice?
Quote:
Originally Posted by
dilettante
See the tons of silly examples of file I/O here that suck entire files into RAM then turn around and split that into an array of lines, etc. Poor practice even for a desktop app but it's a common script kiddie hack use by entry level plinkers. Since the days when RAM began to be measured in 100s of MB and even GBs they get away with it more easily and the abuse has ramped up accordingly.
Although this doesn't seem to be on-topic as far as Op is concerned, it's good to see someone with an opinion.
As an 'entry level plinker' who wrote their first program in 1972 I have to take issue. In my day of Mainframes, it was encouraged to get as much into Virtual Memory as possible, as quickly as possible as the Paging Subsystem (as opposed to RAM) was far more efficient than the standard File I/O routines. Now, that may have changed, but I believe than even in Windows the swapping / paging is more efficient that 'standard I/O', but apart from telling people to use things like File Mapping, getting data into storage via reading data all in one go is, in many cases, probably the most efficient method.
As to thinking that an application / programmer 'owns' the machine, that (IMHO) is just crass - Windows has an in-built Scheduler which makes sure that every app has a 'fair share' of the available resources.
@Dilettane: Have you gone on to Decaf coffee or what ? Even by your standards this was quite an 'aggressive' post. IMHO not worthy of you.
Re: Basic Network Practice?
I also would agree that it is good to read large chunks pf data into ram for processing, within reason of course and making effective use of ram along the way. Todays PCs typically have lots of ram that is not being used at any given moment, perhaps as much as 4 gigs free on 64 bit systems it would be foolish to read a file in 256 byte chunks just to avoid using the memory that is free anyway where using 256k or 256 meg would be much much faster for processing.
Yes you could read a file 1 byte at a time but of course a process that could be completed in 10 seconds using more ram could take several minutes or even an hour or more reading byte by byte.
In the case of a file that is 512k it would be fine to read the entire file into ram and split it and would likely be 10 to 100 times faster than reading it line by line and if done properly the extra memory usage is only momentary and should not pose any problems. Reading byte by byte could be 10,000 times slower than reading the entire file at once in such a case.
Re: Basic Network Practice?
Quote:
Originally Posted by
dilettante
You don't really have what anyone would call a client-server application. You have a monolithic application where multiple instances are sharing files on a common file server. For the purposes of application architecture a file server is not a server, just a shared directory.
That's exactly what I think. So I asked.
I thought that the application in the main PC (where the posting and modification of data in the database take place) is what I could call a server side app, while the application in other workstation (where the only process that takes place is the output of data (the displaying of data that are requested from the database located in the server's path) is what I could call a client side app...making the entire project client-server.
But I kept digging the sense in that...Kinda confuse and still looking for answer; why I'm considering that a client-server when the only 'networking' is the sharing of the database file.
Upon realizing that, can you give me an example of a basic client-server application??
And one thing, does my setup good? Or a more efficient and better way is available and more appropriate?
