CabTrack is a stripped down example of a central site polling a series of remote sites for data updates.
The remote sites accumulate data in a disconnected Recordset until polled via HTTP. Then the accumulated Recordset is serialized and returned to the central site, where it is posted to a database. A fresh empty disconnected Recordset is created and accumulation begins anew.
In the colorful scenario portayed here the central site is a small taxi company's garage and offices. The remote sites are the company's taxicabs, connected via a wireless network subject to the usual interruptions one would expect. "Cab" data is just simulated GPS coordinates generated randomly.
Web Servers? Where We're Going We Don't Need Web Servers!
Instead of a full web server we'll use a simple, single-connection, HttpResponder UserControl built on top of a Winsock control.
This means no web server to install, administer, and in general babysit constantly.
To allow testing with multiple "cab" programs running on the same PC as the "cab tracker" program each cab program instance is assigned a separate port number. These are taken from the Roster.txt file. Each cab needs a copy of the file in order to know what port to listen on, and the cab tracker needs the file to know who to poll. In a real application the cabs would have separate IP addresses or host names, so they'd use the same port (e.g. 80). However a roster of who to poll would still be required in some form by the cab tracker.
CabTracksRs.xml
Each cab needs this file for creating empty Recordsets to accumulate data into. The file is created by the cab tracker when the database is created. After being created it could just as easily be compiled into Cab.exe as a resource, but a file makes things simple for demonstration purposes and would allow easy updating if the database schema changed.
For the demo both Cab.exe and CabTrack.exe share Roster.txt, and all instances of Cab.exe share the same CabTracksRs.xml file.
Requirements
Nothing special. Any PC with a version of Windows that includes WinHttpRequest 5.1 will work, even the dead Windows XP SP1 or later or Windows 2000 SP3 or later.
And of course you'll need VB 6.0.
Testing the Demo
The easiest way to test is to compile Cab.vbp, then compile or just run CabTrack.vbp one time. This first-run creates the database and CabTracksRs.xml file.
After that you could edit Roster.txt or just use the one provided which allows for 3 cabs.
Then you can run one to three Cab.exe instances (or more if you extend the Roster). For each one you check its address from a ListBox it displays, and then click on Start. As they run you can check or uncheck the "Send XML format data" checkbox. The default is ADO's native binary ADTG which is almost always more compact.
The first instance of Cab.exe should result in a Windows Firewall prompt unless you have the prompt option turned off. You can approve or deny this since we don't need to communicate outside the PC for this demo.
Now run CabTrack.vbp, or CabTrack.exe if you have compiled it.
Why WinHttpRequest?
This gives us a fairly neat HTTP client implementation that includes easy access to async events and easy control over timeout values. It also does not make use of the UrlMon/WinInet cache so we don't need to worry about forcing fresh fetches for each request.
In a real application you might wrap several instances of it in a connector/dispatcher class. These would be round-robined in parallel for each poll cycle so awaiting timeouts for out of service cabs or those not in network range wouldn't slow things as much. That is not demonstrated here in order to keep the demo tiny, so polling is done one cab at a time.
You could just use naked TCP too, but (a.) you have to write a bit more code to do so and (b.) ad hoc ports and protocols are not as firewall-friendly as HTTP. Plus you'd have to invent another protocol layer on top of TCP anyway, so why not just use HTTP?
The remote sites accumulate data in a disconnected Recordset until polled via HTTP. Then the accumulated Recordset is serialized and returned to the central site, where it is posted to a database. A fresh empty disconnected Recordset is created and accumulation begins anew.
Image may be NSFW.
Clik here to view.
Clik here to view.
In the colorful scenario portayed here the central site is a small taxi company's garage and offices. The remote sites are the company's taxicabs, connected via a wireless network subject to the usual interruptions one would expect. "Cab" data is just simulated GPS coordinates generated randomly.
Web Servers? Where We're Going We Don't Need Web Servers!
Instead of a full web server we'll use a simple, single-connection, HttpResponder UserControl built on top of a Winsock control.
Image may be NSFW.
Clik here to view.
Clik here to view.
This means no web server to install, administer, and in general babysit constantly.
To allow testing with multiple "cab" programs running on the same PC as the "cab tracker" program each cab program instance is assigned a separate port number. These are taken from the Roster.txt file. Each cab needs a copy of the file in order to know what port to listen on, and the cab tracker needs the file to know who to poll. In a real application the cabs would have separate IP addresses or host names, so they'd use the same port (e.g. 80). However a roster of who to poll would still be required in some form by the cab tracker.
CabTracksRs.xml
Each cab needs this file for creating empty Recordsets to accumulate data into. The file is created by the cab tracker when the database is created. After being created it could just as easily be compiled into Cab.exe as a resource, but a file makes things simple for demonstration purposes and would allow easy updating if the database schema changed.
Image may be NSFW.
Clik here to view.
Clik here to view.
For the demo both Cab.exe and CabTrack.exe share Roster.txt, and all instances of Cab.exe share the same CabTracksRs.xml file.
Requirements
Nothing special. Any PC with a version of Windows that includes WinHttpRequest 5.1 will work, even the dead Windows XP SP1 or later or Windows 2000 SP3 or later.
And of course you'll need VB 6.0.
Testing the Demo
The easiest way to test is to compile Cab.vbp, then compile or just run CabTrack.vbp one time. This first-run creates the database and CabTracksRs.xml file.
After that you could edit Roster.txt or just use the one provided which allows for 3 cabs.
Then you can run one to three Cab.exe instances (or more if you extend the Roster). For each one you check its address from a ListBox it displays, and then click on Start. As they run you can check or uncheck the "Send XML format data" checkbox. The default is ADO's native binary ADTG which is almost always more compact.
The first instance of Cab.exe should result in a Windows Firewall prompt unless you have the prompt option turned off. You can approve or deny this since we don't need to communicate outside the PC for this demo.
Now run CabTrack.vbp, or CabTrack.exe if you have compiled it.
Image may be NSFW.
Clik here to view.
Cabs 0 and 1 in service, Cab 2 out of service
Clik here to view.
Cabs 0 and 1 in service, Cab 2 out of service
Why WinHttpRequest?
This gives us a fairly neat HTTP client implementation that includes easy access to async events and easy control over timeout values. It also does not make use of the UrlMon/WinInet cache so we don't need to worry about forcing fresh fetches for each request.
In a real application you might wrap several instances of it in a connector/dispatcher class. These would be round-robined in parallel for each poll cycle so awaiting timeouts for out of service cabs or those not in network range wouldn't slow things as much. That is not demonstrated here in order to keep the demo tiny, so polling is done one cab at a time.
You could just use naked TCP too, but (a.) you have to write a bit more code to do so and (b.) ad hoc ports and protocols are not as firewall-friendly as HTTP. Plus you'd have to invent another protocol layer on top of TCP anyway, so why not just use HTTP?