Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Networking 3

Status
Not open for further replies.
gwar2k1

gwar2k1

Programmer
Apr 17, 2003
387
0
0
GB
Well Im setting out on my most adventurous project yet. To incorporate network capability into a program i shall be writing.
After a pretty strong analysis of the user requirements, a networked solution would make them quite happy, even if it were to be just two computers connected together.

The thing is, I have not got a clue where to start. I guess I'd have to write a communications unit. The preferred solution is a wireless lan (probabally using a wireless adaptor card in each PC, though it may be that I have to have them connected via ethernet card and good old coax.

So my question is: Where do I start?

Of course, all help will be aknowledged in the final build as ever (not that you'll ever see the source code (I doubt you'd ask)) and will be appreciated dearly.

Thanks...

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Sort by date Sort by votes
So absolutely no locking then ;)

Shame. Oh well. Thanks all

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Upvote 0 Downvote
Maybe it's better using a lock file (skip the name part for that sake), than not using anything!

I see some discussions around, also 'real' programs like java script etc uses lock files to simulate the functionality.

Here's some 'low level' info regarding Pascal/DOS records:


But thats a very OS specific, it might not work for example on a Novell server..?
 
Upvote 0 Downvote
In Java you can work with threads; it supports a SYNCHRONIZED macro of which the effect is to lock the memory until you exit the scope.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Upvote 0 Downvote
Forgot to add ...

Java doesn't need to simulate locking. It uses a virtual machine (i.e. a simulated processor) with built-in multithreading capabilities, thus also locking.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Upvote 0 Downvote
Hebbe did you mean Java? I didnt think javascript could deal with files what with it being an internet language and the security risks.

Hmm... simulated processor ;) LOL! No dont worry Im not crazy. Ive given up with locking now but I have thought of something else.

What if the drives on different computers don't get renamed? So on the server there will be the default C
(which I guess I can change on installation) then the connected computers will all also have C:\ drives.

How do I over come the problem of reading a different C:\ drive. I could write in the user manual how to install the software and how to change the drive letter at the same time, but I doub't they'd ever use the manual.



~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Upvote 0 Downvote
I don't know much about Java, but the application I read about probably was a 'quick and dirty' server software.

In a network the server drive letter (if necessary) should be assigned another one on the clients, else the network is not configured properly. Your program doesn't have to handle anything of that.

You can pass the drive path as well as other settings to your program via the 'paramstr' function in Pascal. Then it is easy to configure and launch the software by using a .BAT file (a bit simpler than implementing a config file yourself).

 
Upvote 0 Downvote
Hebbe's code is fine if you're using Turbo Pascal. I can definitely confirm it works on a Novell server, it should work on any server. However, my experience is that it does *NOT* work in a dos box of XP Pro.

Don't give up on the locks--multi-user programs are *NOT* reliable without them. Period.

As for renamed drives--make the program not care. Don't store a drive letter in the first place. Put the data in a subdirectory under the directory where the program is, use ParamStr(0) to find that out. That will deal with renamed drives fine.
 
Upvote 0 Downvote
@Loren: Clever with the drive names.
@Every1: Thanks for the help. I think, if I find anything, I'll be adding the locks to my program pretty much last. So it gives me a fair bit of time for research.

Thanks again =D

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Upvote 0 Downvote
In WinXP, you can map a network drive like so:
Open "My Computer"
Select Tools->Map Network Drive...
Choose the drive letter to which the network drive should be mounted (e.g. "Z:")
Choose the network drive (e.g. "server\\e\database")

Now you can assign files that reside in the directory "database" (or deeper) on drive "E:" on the computer with name "server" to a Pascal variable:
assign(f,'Z:\data1.db');
reset(f);
...

I expect the network drive mapping procedure is similar under Win2000 but I don't know how it's done under Win9x.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Upvote 0 Downvote
How would i go about reading a unit that's been compiled? the guy that distributed it doesnt have the source (or does he: *.lfn *.tpp *.tpu *.tpw)

Theres also a unit on SWAG so Im gonna check that out (last resort).

Actually it looks like borland have the answer:




~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Upvote 0 Downvote
=D thanks everyone

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
 
Upvote 0 Downvote
I wouldn't leave the locking until last--that just about guarantees you will have problems. When dealing with a multi-user situation you must keep locks on your mind as you are writing it.
 
Upvote 0 Downvote
Actually another thought did occur to me, but it's not elegant.
If you have a series of client programs that need to look at a database file on another computer, which will also run a program managing that file, then you could potentially do it like this:

All clients can read the database (read only)
If a client wishes to change the database, it writes a single file containing instructions about what it wants changing. This file has a unique name made up of something indicating what machine is doing the writing, and a serial number incrementing for that machine. In this way no two machines should ever generate the same file name.
The data-base computer has a "management" program that can continually look out for these instruction files. If it finds one, it reads it to check it's complete. If it isn't, it ignores it until it is.
A complete file is read, interpreted, and deleted by the management program. The management program then produces an updated database, deletes the old, and renames the new.

In this way, no two programs can ever be writing the same file at the same time. There is no chance of a client reading the database while it is being written, since it is written in another name and then renamed, and I'd imagine renaming on most operating systems is pretty much "atomic" in that no operating system worth its salt is going to allow remote file access to a file that it itself is in the middle of working on.
The worst case scenarios are (1) that a client tries to read the database between deletion and renaming. In this case it gets a simple "file not found", and can wait a few seconds and try again. (2) Two clients are trying to modify the same record. In this case it is down to the servicing program to decide which of the two conflicting instructions gets priorities.

i.e. proper locking is better!
 
Upvote 0 Downvote
It might work if you only consider the "syntax" aspect, but what about the semantics? Say, client 1 updates a record and client 2 tries to read this record, it is not certain if client 2 receives the older or the newer contents. If client 1 adds a record and client 2 tries to read it, the record might not even exist yet!
You mustn't forget that, if a lot of clients are connected, the queue of instruction files might be so long that a read operation is never sure of having the latest value; in fact, it might be a value that had actually already to be changed (according to the queue) multiple times.

Also, decoupling read and write operations is not a good idea, partly because of the aforementioned facts and partly because, from an application engineering point of view, you should keep things abstract and uniform (i.e. you should perform read operations with an instruction file too).

Another weak point is the timestamping method: in stead of using a client-specific timestamp, you should use a global timestamp that increments with each operation.

A lot of the mentioned problems flow forth from the fact that a message passing system with files is used. A direct network connection from client to server would be a better idea. But then again, Pascal might not be the best language to write this sort of application in.

You also could write a user-friendly interface to a mySQL client and use a mySQL server to deal with datafiles.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Upvote 0 Downvote
Yes, Bertv100, I agree with everything. This was strictly limited to being a bit-of-a-botch solution to the original problem and very small expansions of it (original was only two computers, one modifying and one reading). The reason I suggested a client-specific element to the instruction file names is to avoid clients overwriting each other's instruction files.
The main weakness of a system like this, as you are totally right to point out, is that there is a delay between asking for something to be done, and its happening, so during that delay, other processes will be given out-of-date information. That's bad, very bad, but sadly not entirely unknown in lots of aspects of life....
 
Upvote 0 Downvote
I might be getting a little too philosophical about things, but I consider computers exist to eliminate errors from the aspects of life.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
 
Upvote 0 Downvote
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top