FTP vs. COPY 1

[johncook]

I have 2 VFP apps. One is a mobile POS system. The other is basically a bank.

Currently at start of day, bank downloads ALL balances to floppy which is imported by each mobile POS app. Sales are made on mobile POS app. At end of day, each POS unit exports to a floppy, it's sales data. Bank app reads floppies and balances are updated with the sales info.

Need to move to real-time. We are setting up a wireless network which the mobile POS units will use to communicate with the bank.

Basically rather than a floppy containing ALL balances, the mobile units will request an individual balance from the bank as needed. The bank will send the individual balance to the mobile unit. The mobile unit will perform a sale, at the end of which, it will send that individual sales data to the bank.

The bank is running on a network workstation. I perceive a workgroup that both the bank and multiple mobile units belong to. I perceive shared folder's on both the bank workstation's HDD, and on each mobile unit's HDD.

My question (finally), of which there are 2:

1. Should I use FTP or just be copying files between the 2 apps? I believe the multiple POS units shared folders, would all be named the same. I am wondering if copying, rather than FTP'ing (to a particular IP Address or something like that), how would the bank address a particular POS units HDD?

2. I have basically defined the following files as being passed between the apps, and would like to know (big picture) if my approach sounds reasonable. With all the new communications software perhaps I am way off base. The files:
POS requests an individual balance
Bank sends confirmation that request was received
Bank sends individual balance and locks account
POS sends confirmation that balance was received
POS sends sales data
Bank sends confirmation that sales data was received
Bank updates account and unlocks account

Thanks for any guidance,
John

 

[DSummZZZ]

Another option may be worth considering. Try the "Winsock Chat / Communication Utility" I have posted on my web site.
Follow the link below my signature, and scroll down until you see it.
Modify it to send a transaction to the server, await a reply, and go from there.
You won't have to keep copying files back and forth, just a transaction at a time.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[wgcs]

I'd also recommend direct network communication instead of transferring files.


Explore Web Services & SOAP, that can basically provide you with a server program providing services that are accessed through HTTP like any web page. You have to arrainge for authentication, etc, but newer versions (7,8) of VFP are pretty adept at web services.

 

[johncook]

Dave,
I downloaded but when I run it wants an IP address. My network experience is limited. I know what an IP address is but I am developing on a standalone PC. Yes, I wll be developing on a network but for today that is not an option.

WGCS,
I have heard of SOAP, etc but that is all. What is direct network communication rather than transferring files?

Do I not have to manage the movement of the files so that both apps know the status of any particular request or file sent?

Thanks,
John

 

[DSummZZZ]

...it wants an IP address...

The server portion grabs the IP address from the machine it's running on. The client needs the address of the computer where the server is running, which for testing would be the same, ie., your own address.
You should be able to use either the word LOCALHOST as the address, or 127.0.0.1 while you are running standalone.

When you get on the network, you can find it by going to a command prompt and run ipconfig or winipcfg.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[johncook]

Dave, I have it running. That's neat but I am unsure exactly how I would use it.

It appears thet the actual data that is moved back and forth must be stored internally, i.e. some sort of temporary table somewhere?

Is this like COM object that I would have each app sending data to?

Sorry for my ignorance,
John

 

[wgcs]

Dave's example provides you with a 'communication pipe' that your two applications can talk through.

How you go about negotiating what data goes where is up to you: design commands that can:

Request a record
Send a record
Send an Update to a Record

The "record" can be whatever smallest working unit of data you need. The server program maintains the actual data... the satellite programs just deal with a small bunch of data at a time.

 

[DSummZZZ]

To elaborate on wgcs's post, picture the 'Send test message' button on the client, as the 'Save' button on your form. When the 'Save' button is clicked, you would gather up the data, concat it into a single string, and send it to the server rather than just a test message.
On the server, you would receive the message, parse it, and add it to the table. Upon successful update of the table, you could then send an ACK message from the server to the client letting the client know the record has been added to the master table.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[johncook]

That's all great! It really sounds like a nice solution for what I need.

One more question: Can I run this where the forms are invisible? I guess I am assuming the client and server classes can be started, then my program just USES them for the communication i.e. I "tell" the client to send a message to the server and have some way to interrogate the client for messages received from the server, etc.?

Thanks all,
John

 

[wgcs]

Sure: you can rearrange things however you want.

You could leave it all contained in the form objects, or you could add the communication stuff to your own application class (which could be an invisible form itself).


What architecture is your application right now? (Main.PRG calls form x, etc.)

 

[johncook]

Normally that would be an easy question to answer. Not this time.

The app that would be running the server class is VFP 7.0 using Visual FoxExpress(VFE) framework. It has the usual foxpro style menu and most of the forms are run from the View... menu.

I suspect I will be adding a timer object to this server app. It will start when the app is started and will be doing the server's sending and receiving to and from the client's, in the background.

The app that will use the client class is a strange animal. I originally wrote it in FPW2.6 and upgraded to VFP 3.0 then 7.0. No framework. Basically 2.6 style code run thru the converters. I do have the tables in a DBC.

This POS app is a touch screen app and real tricky which I believe will effect the way I use the client class.

Picture your monitor split in 1/2 vertically. 2 users are doing sales entry simultaneously. Each user is waiting on their own customer. 2 barcode scanners are attached. The program is basically a big inkey loop that keeps up with what each user is doing and acts on data received thru the keyboard port (scanners sending an id to indicate which side the data is destined for) or by touching the monitor in which case the program knows which side of the screen was touched and acts accordingly.

The reason I mention all that is to get to this: A user will scan a customers wristband which contains their ID#. Upon doing so the client will send a request to the server asking for the current balance for that ID#. As a user completes a sale, the user will scan the ID# again, signifying to save the sale transactions, in which case the client would send the sales data to the server.

If possible, it may be best to have 2 clients running on each client PC. Not sure if that is possible or even the right thing to do at this point.

This POS app really has no forms as such. It is the OLD DEFINE WINDOW stuff. Hope this helps,
John
P.S. The PC's that the POS apps are run on are mobile panel PC's kind of like laptops. They are moving around all day.

 

[wgcs]

I suspect I will be adding a timer object to this server app. It will start when the app is started and will be doing the server's sending and receiving to and from the client's, in the background.

I think you will want the server to immediately respond to events generated by the TCP/IP connection/conversation, instead of being timer-based.


. 2 users are doing sales entry simultaneously. Each user is waiting on their own customer. 2 barcode scanners are attached.

Do you mean that both barcode scanners are connected to the same client computer, or is each scanner attached to it's own client computer?


This POS app really has no forms as such. It is the OLD DEFINE WINDOW stuff.
The DEFINE WINDOW command actually instantiates a form object.... though that doesn't help with the TCP/IP communications. I don't think it should take very long to convert the old FPW windows to real Form classes: I'd guess that half the code would just go away (because the information it contains gets stored as the class hierarchy of the form design instead), and the rest of the code would get much simpler. The new form could easily host the client side of the TCP/IP communications.


As a side note: I would advise connecting and disconnecting for each transaction (not too frequently, but don't expect to connect in the morning and have it stay connected all day..). Cordless phones and cell phones can disrupt a WiFi TCP/IP connection, necessitating a re-connect.

This gives a hint at how your communications protocol should be designed: Don't commit anything at the server end until the full communication is received from the client. And be ready at the client to resend the whole communication if no confirmation is gotten from the server that it is complete. And if a client is resending a transaction that the server already got (but the confirmation from the server was lost) enable the server to recognize that, and either cancel the send (if it's long) or just receive it and throw it away.

 

[wgcs]

Here is an example client server conversation (every line ends with CHR(13) which tells the other side that the whole line was successfully sent):

This example illustrates an authentication mechanism and a transaction request system that is safe for multiple clients charging the same customer concurrently for different transactions.

The first conversation gets the balance.
The second conversation updates the balance successfully.

** double asterisk (**) preceeds my comments on what's happening
** >> indicates sent from client to server
** << indicates sent from server to client

** Client connects to server
** Authentication Challenge-Response layer:
>> HI MYNAME=JoeSchmoe
<< HELLO NAME=JoeSchmoe CHALLENGE=fa898awfw
** Client takes "fa898awfw" and combines it somehow with
**   the password supplied locally when the user (JoeSchmoe) first
**   turned on the remote workstation, and returns 
**   that appropriate response:
>> LOGIN RESPONSE=jsd0u09jkl3j
<< WELCOME NAME=JoeSchmoe
>> GETBAL CUSTID=12345
<< CURBAL CUSTID=12345 BAL=100.00
>> BYE
** Client Disconnects
** Client scans a bunch of stuff ($250.00), 
** then is told it's done (by scanning the customer ID again)
** Only the change is sent to the server, since the 
**  same customer ID potentially was used in another
**  transaction down the hall...:

** Client connects to server
** Authentication Challenge-Response layer:
>> HI MYNAME=JoeSchmoe
<< HELLO NAME=JoeSchmoe CHALLENGE=s8disojdf8
>> LOGIN RESPONSE=988sa9f98sdf
<< WELCOME NAME=JoeSchmoe

** Client gets a unique transaction ID from the server
**   to be able to verify that it gets committed
>> GETTRANS
<< NEXTTRANS ID=11111
>> UPDBAL CUSTID=12345 DEBIT=250.00 TRANSACTIONID=11111
<< CURBAL CUSTID=12345 BAL=-150.00
** The balance was recieved, so the transaction was committed
>> BYE
** Client Disconnects


** This illustrates the fail-safe mechanism:
>> HI MYNAME=JoeSchmoe
<< HELLO NAME=JoeSchmoe CHALLENGE=s8disojdf8
>> LOGIN RESPONSE=988sa9f98sdf
<< WELCOME NAME=JoeSchmoe
>> GETTRANS
<< NEXTTRANS ID=11112
>> UPDBAL CUSTID=12345 DEBIT=250.00 TRANSACTIONID=11112
** Unexpected disconnect!!!  Did the transaction happen??

** Client Tries again:
>> HI MYNAME=JoeSchmoe
<< HELLO NAME=JoeSchmoe CHALLENGE=s8disojdf8
>> LOGIN RESPONSE=988sa9f98sdf
<< WELCOME NAME=JoeSchmoe
>> UPDBAL CUSTID=12345 DEBIT=250.00 TRANSACTIONID=11112
<< ERROR MSG=Transaction_Already_Committed.
** Yup, the transaction was already committed!
** If it hadn't been committed, we would have gotten
**  the expected response:
** << CURBAL CUSTID=12345 BAL=-400.00
>> BYE
** Client Disconnects

Some suggestions: Establish rules for your protocol so that it is easy to parse, say:
All statements start with a statement Identifier in all caps. (some internet protocols require all statement identifiers to be the same length, and to be followed by a number that is language independant...I don't see the need for the number)

All statements are composed of Name=Value pairs
All Values have no spaces in them (this makes it easy to separate the name=value pairs by spaces)
All spaces within values are represented by "_", the "_" character is represented by "\_" and the "\" character is represented by "\\"
etc. These are, of course, just examples.

 

[johncook]

WGCS,
Thanks! I believe I understand everything you are telling me. I have conceptually performed many of the same tasks in prior projects, only not with such a wonderful "pipe mechanism".

I believe the connecting each time answers my need for multiple clients on same PC. That makes sense.

Just because you asked, yes there are 2 barcode scanners attached to the same client PC. A better way to picture this is probably if you went to Chili's and looked at their touchscreen POS screen, but shrink their POS forms to only use the left half of the screen. Say the right side is just blank. Now duplicate what you see on the left, on the right. Now add a second credit card reader (one on left and one on right)and make the app smart enough to allow 2 waitress's to do all the things they do with this app, simultaneously.

Thanks again. I hope to have this defined well enough by middle of next week to begin coding. I am sure I will have further questions.
John

 

[wgcs]

Feel free to ask away!!

FYI: Most of what I've learned about TCP/IP protocols comes from studying SMTP,POP3 email and FTP protocols. There are certainly other ways of going about things, but it seems to me that this 'conversation' method is most clearly envisioned and implemented.

You might learn a fair amount by looking closer at the RFC's for these protocols.