Networking 3

Doing everyting the low-level way (NetBIOS) would be like re-inventing the wheel. Personally I would use TCP/IP protocol and let the OS manage connections, data transfers and correction. Also, I wouldn't use Turbo Pascal, maybe Delphi (you can probably use Winsock there) or, since I'm a little more familiar with it, C++.
I made a server and client application in C++ using DvNet (networking), DvThread (interface to POSIX threads) and DvUtil (various functions). These libraries are written by Dirk Vermeir (a professor at the Free University of Brussels) and are only available for Linux. You can find them here:
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.

I run one simple pascal program on a w98 client against a Novell server. I just changed the drive letter and path to the server as it appear in file-explorer. No problems.

That would work if you only want to share files. However, if you need direct communication, you need a port-to-port connection.

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

its just sharing files. I dont need messaging or anything, i just need a database to be updateable on one comp and then viewable on another.
Though I would like it to be maintainable so I guess the messaging would be somthing Id have to look at in depth.

So Im going with TCP/IP protocols? *searches google* Im reading up on wireless TCP IP and PCMCIA cards cause that's what Im going for.

Why am I doing it in Pascal? Its the last (big) project Ill do in Pascal and I wanna go out with a bang =D

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

The wireless aspect and the type of network card are irrelevant if you use TCP/IP; these things should be resolved by the OS.

If you need a direct connection, you have to let the server application set up a server socket that listens on a specified port for incoming connections. Whenever such a connection is established, you can either transfer it to another port (so that other connections can be made) or leave it at the current port (in this case you will only be able to connect one client at the time with the server).

If you only need file sharing, you can mount the remote harddrive (on which the files to be shared are located) locally to a drive letter and use this drive in Pascal as if it was a local drive (e.g. local drive = C: remote drive mounted to Z: )

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

So I wouldnt need to tell any hardware what to do, I'd just write to a drive on another computer?

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

It should work, yes.


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

>its just sharing files. I dont need messaging or anything, i >just need a database to be updateable on one comp and then >viewable on another.
>Though I would like it to be maintainable so I guess the >messaging would be somthing Id have to look at in depth.

If all you need is file sharing then you don't need anything fancy like TCP/IP.

Network drives look just like any other drive, you simply read/write to them like you would a local HD. Normally you neither know nor care that they are physically elsewhere. (250,000 line application designed from the ground up to be a network app--there's *ONE* routine that actually cares where a file is. It's job is to say who has the file locked.)

What is important is file locking and how you go about updating data.

You must ensure that other computers do not mess with your data while you are in the process of changing it. The simple solution is to lock anything you are using. (Note: You'll have to implement your own lock routines. For some reason Borland neglected them.) So long as that is adequate, no big deal.
However, sometimes you can't be that aggressive about locks. An example from my code: The employee editor for our time clock. There are 3 fields directly editable when displaying the list of employees. If I were to lock the file when it was called up, though, big problems. People need to be able to clock in and out! Thus when the user attempts to change one of those fields I lock it, read it again and compare it to what I already had in memory. If they match, I write the change and unlock. If they don't match I simply unlock, redisplay what I just got from the disk and say somebody else just changed this. Editing the details of an employee leaves the whole employee's record locked because the nature of the situation is that only one person is normally doing such editing at any given time. Someone else who tries to go into the editor at that time is very likely to get a frozen screen waiting for the first person to leave.
The order scheduling program is even pickier in this regard--*EVERY* normally-edited field is protected by such a routine. There is nothing that waits for a key between the lock and the unlock.

I have designed a boolean lock. I guess its not gonna be too secure if Im interpreting yours correctly.

When a field is entered to be edited, it gets a locked value of true. If someone goes to the edit screen after it's been locked, they will not be able to select the field that is currently being edited.
There is also an option for the user to lock the whole record while they are working on it.

Does that sound sensible?

Thanks to all for the info about drives.

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

You *CAN'T* implement your own locks that way--locking must be an atomic operation and check-if-clear-and-write-true is not atomic.

While it's possible to do some of your own locking (if you wish to deny specific operations but permit others) at the heart of it you *MUST* use the system-provided locking facilities. You can build upon them, you can't replace them.

When it comes to locking, "not too secure" won't cut it. It's perfect or it's a disaster waiting to happen. Always figure that the other program is watching, waiting to pounce at the most inopportune time. (This tends to be reality--when it hits a lock the OS will retry a bit, so the other program likey *IS* waiting to pounce.)

=$ my first attempt at locking hehe. Okay thanks, I'll take that in and work on it.
When you say "the system-provided locks," what do you mean? Cause Im writing the system myself

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

In a multitasking/multithreading environment the operating system provides routines to lock and unlock parts of the shared memory.
Example:
A travelling agency books reservations on a plane, the number of free seats is an example of "shared memory", travel shops are threads.
Travel shop #1 wants to book 2 seats and checks if they are available, if so, it decreases n by 2.
Travel shop #2 also wants to book 2 seats and also checks if these seats are available, if so, it decreases n by 2.
If no locking would be used, what would happen if n=2 and the following scheme would be used: At the end n would contain the value -2!

When implementing locks, only one thread at the time can access a certain memory location and the scheme would look like this: In this case, Travel shop #1 gets the 2 seats. The order in which each undividable operation is scheduled, however, is completely arbitrarily. If Travel shop #2 would have received the first lock, they would have had the 2 seats.

This explanation illustrates the need of locking and the need of an OS that supports it. How it can be used from within a Pascal program, I don't know.

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

Oh. I didnt know OSs had anything to do with the locking. Hmm...

Loren, can you explain what an atomic operation is please? And why its used instead of my proposed method. Cheerz

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

An atomic operation is an undivisable operation; i.e. an operation that is always performed as a whole and thus never split into two parts by the OS' scheduler. An example would be obtaining a lock: internally, the OS will check if there already is a lock and if so, deny the lock request, or else grant it. If obtaining a lock would be nonatomic, (divisable) the same problems arise as for which locking was invented in the fist place!

The reason why only the OS can issue locks is that only the OS decides in which order the application chunks will be executed. Any lock handler has critical program parts that may not be split into two or more chunks; making sure this doesn't happen requires that the lock handler be embedded in the OS.

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

Ah I see. Dang.

Thanks

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

Would this work (one database, another lock file)?

The lock file must have the same name for different 'clients', but different names for different database files possible.

If a 'editing' client falls off, the lock file must be deleted manually.

While the basics of your solution would work (no need to wait, just leave the file open. In fact there's no need to write anything.) it's horribly inefficient and it's just using the system's own locking facilities in another fashion.

Quit trying to dodge the manual, lock it correctly. The principles are the same no matter what the language.

To be honest, I don't even need them... well I wouldnt say I did: One user reads a file, One user updates the file.

I just wanted to include them incase, you know maintaing the system. Im running test runs with my method and Im gonna use your comments from before and see if I can come up with something special.
I get that its not going to be as good as regular off the shelf software or anything you guys make but it'll do for my proposed user.

Im also gonna look around, see if anyone does know a way to use the operating system's locks with Pascal. No doubt I wont if Bert doesnt know And even if I do it'll be over my head.

Thanks for all your help

~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."

No, the lock-file thing doesn't work. It has the same problem as before.
This is the sequence of events.

Prog 1 looks for a lock file, doesn't find one.
Prog 2 looks for a lock file, doesn't find one.
Prog 1 writes a lock file with its name

Someone asks the OS that's running prog 2 to do something big, and there's a delay.

Prog 1 reads the lock file and finds its name, and is now happy.
Prog 2 finally gets a look in and writes its lock file with its name.
Prog 2 hangs around a bit
Prog 1 meanwhile modifies the data file at will
Prog 2 reads the lock file again and still finds its name
Prog 2 starts to modify the data file at the same time as prog 1.

The difficulty is that only the operating system can decide how much processor time the two progs get, and in what order. You can't guaruntee the sequence of the thing at all. This is why file-sharing MUST be handled by the OS. The hard disk where the data are belongs exclusively to 1 OS, which means this 1 OS can control how many people are using that file, exclusively.

In fact, if the OS isn't going to do file-sharing for you, why bother having an OS? Managing files is really one of the biggest roles of the OS.