IBM ARTour Kickoff
ARtour kickoff in San Mateo, 8/15/96. See http://www.raleigh.ibm.com
Protocol gateway to a variety of wide-area wireless that provides sockets
interface and does various network level optimizations.
- Client "agent" at network level talks to its peer on a server
(which is behind the physical network gateway): like MOWGLI or evil twin;
gives sockets API and provides protocol gateway (ie no TCP/IP over wireless).
- "Optimized access" for TCP/IP legacy apps with no modification.
Apps that don't tolerate timeouts well, etc. may need to be modified.
(Intel was trying to enable this in middleware). Apps that don't use
network efficiently will work but perform poorly.
- Client: DOS/Win with IBM TCP/IP for DOS or OS/2; server peer: OS/2
or AIX; gateway to physical network: AIX on RS6k with X.25 card. Single
gateway can gateway to multiple WWANs; ARtour has provision for switching
among available ones (can switch TCP on the fly).
- CDPD: ARtour will run on top of it even tho CDPD provides its own full
stack. (Trivium: CDPD bills you before compression, so you should always
do it at the client.)
- Wireline encryption and authentication via CDMF (commercial deriv.
of DES), all the way to the gateway (scenario: gateway is also intranet
- SNMP-aware AIX wireless network graphical monitor app (topology/users,
- Standard optimizations: header compression/reduction, stream compression,
packet filtering, connection muxing, etc.
- Claim: network-level adaptation to QoS as you switch networks by varying
- Currently works w/ARDIS, RAM, ARDIS; others coming.
- Software developer program: get a free modem, free access to IBM gateway,
cheap airtime on partner networks.
WebExpress and 3270 "agents" ("emulators")
- API for interposing transport-level or app-level agents, intended for
apps that export well-circumscribed API.
- HTTP header compression, forms differencing via CGI, HTML stream compression,
etc. Very much like MOWGLI. (Claim: 90% reduction in some cases for
Web traffic. Basis of claim is differencing of CGI forms where only a
few bytes of content actually differ!)
- Images: currently, passed through. Future, user will be able to specify
certain datatypes should not be xmitted to client.
- CLient-side cache: you hardwire the refresh interval! Just an extension
of the browser mechanism for cache consistency. (They shoudl be refreshing
cache when reconnected to wireline! They didn't mention this, but they
do mention priming the cache before disconnecting.) Future plan: cache
refresh policy can be based on URL's, etc. (MOWGLI has something like
this for locking items in client cache)
- "Differencing"of CGI-generated pages (i.e. run consecutive
CGI reqs to same service, and run "diff" at the server peer).
Not clear how general/extensible this approach is.
- "This is not an ad-hoc surfing product, but a business tool [for
accessing web-based c/s apps, etc.]. You won't pay to surf the web over
- Currently in beta! Expect release end of year.
- Things that itdoes not seem to do: traffic choreographing; compression
in the cache.
- They are actively courting customers to adopt this as a middleware
standard. Their main concern: new platforms, new networks.
- There's a fundamental limit to what you can do below the application
Back to index