keeping http clients up to date

[Michael Oberleitner]

Hello

I have a client-server-application where the clients are able to call methods on the server, to write information to the db. The clients have the informations from the db stored locally in the ram, so they just need to call the server to write, but not for reading.

When a client now writes to the server, the server needs to send a 1-to-n message to all clients, to give them the new written information and to keep them up to date.

I tried this with http, but with http the server is not able to initiate a communication with the clients, i think.

The question now is, is there a way to achieve this with http or is it better to use another rpc technology like rmi for this.

I hope someone has experience with such kind of problems and is able to give me an advice.

Kind regards,
michael

[Bear Bibeault]

Ajax on the pages can periodically poll the server fro updated info.

[Pat Farrell]

Michael Oberleitner wrote:the server needs to send a 1-to-n message to all clients, to give them the new written information and to keep them up to date.
..... but with http the server is not able to initiate a communication with the clients

As @bear said, AJAX is one solution.

You have a fundamental problem. The HTTP RFCs are very clear, the client initiates all communication. There is nothing that the server or anything on the server can do to initiate communications. Period. So have the client periodically do a refreshing query.

[Jayesh A Lalwani]

Why do the clients keep data in memory? Can't they fetch the data from the server when required? Are they doing some processing that requires all data to be on the client?

[Pat Farrell]

Jayesh A Lalwani wrote:Why do the clients keep data in memory? Can't they fetch the data from the server when required? Are they doing some processing that requires all data to be on the client?

I'm just guessing, but supposed the application has the current prices of a bunch of stocks. Each client can submit buy and sell orders, changing the price.

The user expects to look at the screen and see the "current" price.

The only way to do that with a browser and a Java container is by having the client (HTML page, JSP page, etc.) periodically talk to the server.

[Rob Spoor]

Although the technique is not yet finished (I believe Internet Explorer has zero support), WebSockets could also be a solution to this problem. Unlike AJAX, where the client has to poll the server, web sockets allow a server to push messages to clients.

[Michael Oberleitner]

Thanks a lot for your help

I forgot to say that the client is a desktop client made with swing. Later it's possible that a webclient will also be implemented and that's the reason why i chose to use a HttpServlet.
I try to build a client where the information gets pushed from the server to the client, because of the traffic that will arrive when for example 50 clients are connected to the server which all update there information every 5 seconds...

I think, for the desktop client, it must be possible to achieve this with rmi and in the web i found this: http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html

When you have any ideas about this i would appreciate to here.

Kind regards,
michael

[Rob Spoor]

I've actually had to do this myself. The Tomcat server receives HTTP requests from two sources, and uses RMI to communicate with the clients. These need to register/unregister themselves so the server knows where the clients are located. It works pretty good.

[Tim Holloway]

So, in summary:

An HTTP client is limited by the HTTP protocols. You cannot broadcast or send any form of unsolicited data from an HTTP server to HTTP client(s), only send responses to client requests. For web clients, this can be done by AJAX polling. For a Swing app, just kick off a request from a timer-driven thread. Usually REST format works best for stuff like this.

Swing apps (and Java Applications in general) can use RMI to talk to servers. RMI is not HTTP. It communicates in binary (HTTP is text-only), but RMI clients can register callbacks, which, unlike HTTP, can be posted to asynchronously without the client having to make a request to get a response. RMI is fairly efficient, but it can be a problem over the open Internet, since it uses different ports and protocols than HTTP, and may be blocked by firewalls that weren't configured to be RMI-friendly.

It's possible to combine strategies. Enterprise JavaBeans (EJB) were originally conceived as RMI server objects, and while they are more commonly used as server-local components these days, it's possible to define both local and remote interfaces on EJBs, which is handy because you can then use the same EJB to encapsulate functionality for both HTTP- and RMI-based clients. However, Tomcat doesn't support this as a native feature. But JBoss is a full-stack JEE server which does (using an embedded Tomcat), and in fact, any full-stack J2EE/JEE sever will, including both open-source (Glassfish, Jonas) and commercial (WebLogic, WebSphere).

[Jayesh A Lalwani]

One thing to note if you are going the RMI route is many corporate firewalls block RMI ports and they will not open them even if you ask them nicely. If you are making a client that is intended to be used anywhere, you might want to start looking at solutions that tunnel RMI over HTTP. I am fairly certain that most firewalls will block any incoming RMI/HTTP. So, if you are considering a solution where the client acts as RMI/HTTP server that the server pushes data to, you will need to check your environment constraints

I think you should really revisit your need to store all the data in the client. If it's an application )like Pat said) that shows the prices of a bunch of stocks, you can always implement this by having the client continuously retreive the stock prices from the server. You don't really need to store the stock prices in RAM. If you really want to keep data in memory, then a background thread that polls the server for data is the way to go

[Michael Oberleitner]

Hello

I still try to implement this with rmi-callbacks, but now i have a problem because the client is not able to register at the server.

I made a remote interface for the server:

public interface IRegister extends Remote
{
	public void register(IClientUpdate client) throws RemoteException;

	public void unregister(IClientUpdate client) throws RemoteException;
}

and then i implemented the remote object like this:

public class ClientRegistration implements IRegister, Serializable
{
	/**
	 * 
	 */
	private static final long serialVersionUID = -1507423453953642171L;
	
	private Vector<IClientUpdate> clients;
	
	public ClientRegistration()
	{
		super();
		clients = new Vector<IClientUpdate>();
	}
	
	@Override
	public void register(IClientUpdate client)
	{
		System.out.println("client registered");
		clients.add(client);
	}

	@Override
	public void unregister(IClientUpdate client)
	{
		System.out.println("client unregistered");
		clients.remove(client);
	}
}

Maybe it's important to know that IClientUpdate is also a remote object running on the client, so that the server is able to update the clients.
The servlet creates the remote-object in the constructor:

public TreeServlet() 
    {
        super();
        this.typeInstances = new HashMap<String, Map<String, Node>>();
        this.clients = new Vector<IClientUpdate>();
        this.registration = new ClientRegistration();
        
        try {
			IRegister stub = (IRegister) UnicastRemoteObject.exportObject(registration, 0);
			Registry registry = LocateRegistry.getRegistry();
			registry.rebind("register", stub);
		} 
		catch (AccessException e) 
		{
			e.printStackTrace();
		} 
		catch (RemoteException e) 
		{
			e.printStackTrace();
		} catch (UnknownHostException e) {
			e.printStackTrace();
		}
    }

and this is how the client tries to call the remote object:

private void register()
	{
		if (System.getSecurityManager() == null) {
            System.setSecurityManager(new SecurityManager());
        }
		try {
			Registry registry = LocateRegistry.getRegistry("10.4.56.61", 1099);
			IRegister registration = (IRegister) registry.lookup("register");
			registration.register(updateListener);
		} catch (AccessException e) 
		{
			e.printStackTrace();
		} 
		catch (RemoteException e) 
		{
			e.printStackTrace();
		} 
		catch (NotBoundException e) 
		{
			e.printStackTrace();
		}
	}

but when i call this on client wich is running on another machine i get the following error message:

java.rmi.NotBoundException: register
	at sun.rmi.registry.RegistryImpl.lookup(RegistryImpl.java:134)
	at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
	at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:409)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:267)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:679)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:377)
	at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
	at com.inzeit.tcs.model.TCSHttpClient.register(TCSHttpClient.java:94)
	at com.inzeit.tcs.model.TCSHttpClient.<init>(TCSHttpClient.java:59)
	at com.inzeit.tcs.model.TCSHttpClient.main(TCSHttpClient.java:335)
connecting to http://10.4.56.61:8080/TCS-Servlet/TreeServlet
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
	at org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:182)
	at org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:150)
	at com.inzeit.tcs.model.TCSHttpClient.<init>(TCSHttpClient.java:63)
	at com.inzeit.tcs.model.TCSHttpClient.main(TCSHttpClient.java:335)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
	... 4 more

I can ping the server from the client and the servlet functionality still works and when i run netstat -anltp | grep "LISTEN" on the server the output is:

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      3402/redis-server
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::1099                 :::*                    LISTEN      3486/rmiregistry
tcp6       0      0 ::1:631                 :::*                    LISTEN      -               

First i thought that maybe the client tries to call the servers remote object before the server had bound it to the registry, but when i changed web.xml from

<servlet>
    <description></description>
    <display-name>TreeServlet</display-name>
    <servlet-name>TreeServlet</servlet-name>
    <servlet-class>com.inzeit.tcs.servlet.TreeServlet</servlet-class>
  </servlet>

to

<servlet>
    <description></description>
    <display-name>TreeServlet</display-name>
    <servlet-name>TreeServlet</servlet-name>
    <servlet-class>com.inzeit.tcs.servlet.TreeServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

the error message on startup of tomcat is:

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
	java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
	java.lang.ClassNotFoundException: access to class loader denied
	at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:419)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:267)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:679)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:377)
	at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
	at com.inzeit.tcs.servlet.TreeServlet.<init>(TreeServlet.java:98)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at java.lang.Class.newInstance0(Class.java:372)
	at java.lang.Class.newInstance(Class.java:325)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1116)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
	at org.apache.catalina.core.StandardService.start(StandardService.java:525)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
	java.lang.ClassNotFoundException: access to class loader denied
	at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
	at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:409)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:267)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.ClassNotFoundException: access to class loader denied
	at sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:603)
	at java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:646)
	at java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:311)
	at sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:255)
	at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1548)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1510)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1749)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
	... 12 more
Caused by: java.security.AccessControlException: access denied (java.io.FilePermission /home/michael/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/TCS-Servlet/WEB-INF/classes/- read)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
	at java.security.AccessController.checkPermission(AccessController.java:553)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at sun.rmi.server.LoaderHandler$Loader.checkPermissions(LoaderHandler.java:1173)
	at sun.rmi.server.LoaderHandler$Loader.access$000(LoaderHandler.java:1127)
	at sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:569)
	... 20 more

I'm sorry for this long post, but since yesterday i'm really stuck with this. When I forgot something please ask here.

Kind regards,
michael

[Tim Holloway]

One you get thick into RMI, this isn't the best forum. We have a separate forum where the RMI experts hang out.

RMI consists of 2 subsystems. One is the RMI registry, which runs either as a stand-alone application, or as an embedded service in an EJB server. The other is the RMI service itself. You request an RMI service by querying the RMI server for the named service.

Two problems often occur here. If the service isn't set up properly, it may not register and thus the RMI server cannot link the client to the server. The other problem is that classpaths in RMI can get very confusing, since some classes are on the client and some are on the server. I think that this is basically what's happening to you, since it looks like the root cause of your problem is inability to locate one of the apache commons logging classes.

[William Brogden]

I know I am late to this thread, but that notifying all the clients of a change thing sure sounds like Java Message Service in the publish-subscribe mode. All the tangled details of RMI would be taken care of by JMS.

Any particular reason JMS was not considered?

Bill

[Michael Oberleitner]

Hello and thanks a lot for your help.

@ Tim
this

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory

i notice also when i start the client and therefore i added commons-logging-1.1.1.jar to the classpath of the client, but the error message is still the same.
When there will be no progress soon i will send the instances of IClientUpdate without rmi, but just with http, because i think this will be less trouble for me.

@ William
The updating of the clients is not implemented yet and therefore there is still time to make changes. I haven't considered to use JMS, because i never used it before.
Why do you think it should be better compared to rmi?

regards,
michael

[Tim Holloway]

William Brogden wrote:I know I am late to this thread, but that notifying all the clients of a change thing sure sounds like Java Message Service in the publish-subscribe mode. All the tangled details of RMI would be taken care of by JMS.

Any particular reason JMS was not considered?

Bill

Well, the original question was framed in terms of RMI, but sometimes the questions limit the answers. JMS is certainly worth considering.

RMI is, (from my point of view) simpler (especially in the case of remote EJB), probably has less firewall issues, since only the server needs a firewall port, and couples more tightly between clients and server.

However, JMS offers a better subscription model for broadcasting, and allows for the option of delayed delivery for offline clients.

[Pat Farrell]

More fundamentally, why are you using RMI?
The title of this thread is HTTP Clients. You should be using HTTP. A bit of AJAX is trivial to implement. Getting RMI through corporate firewalls is impossible.

[Tim Holloway]

The question now is, is there a way to achieve this with http or is it better to use another rpc technology like rmi for this.

That's why.

Firewalls are a problem on the open Internet, definitely, but we never determined if that was the scope of the system. Internal firewalls are dependent on company policy. I used an RMI server that coupled with a webapp to run a (very) long-running process, and everyone was fine with it. Especially since the alternative - running the process as a thread inside Tomcat - would have held the entire Tomcat server hostage for days at a time.

[Michael Oberleitner]

The general communication between client and server in the application is realized with http and this is already finished, therefore i wrote http clients.

Additionally i want to keep the clients up to date and for this i need more communication and this is:

1. The clients which want to be kept up to date have to register at the server, so that the server knows which clients it must keep updated. This i wanted to make with rmi, but now i noticed that it might be better to use http for this task.

2. The clients need an interface so that the server is able to push modified objects to them. I think this is very difficult using http without installing tomcat to every client and therefore i need another technology. I'm absolutely not sure if rmi is the best way to do this or if JMS for example is better, because the clients also have to communicate over firewalls and the internet with the server. Finally this is the question of this thread.

Kind regards,
michael

[Pat Farrell]

Michael Oberleitner wrote: I think this is very difficult using http without installing tomcat to every client and therefore i need another technology.

I think you are confused. There is never a reason to install Tomcat on each client machine. I have a hard time even guessing how you got to that.

Lets back up.

A) Did you write a Java application that runs on the client side that talks HTTP to a normal Tomcat Java application?
B) OR are you writing a normal JEE Java application running on Tomcat that talks to a browser (IE, Opera, FireFox, Chrome, etc.)? This presents solutions
in a normal HTML/JSP page, perhaps with some Javascript

I, and most of the folks responding here assume you are talking B.

If you are talking A, its a lot more complicated. Most folks would use design B.

With design B, you don't use RMI, you use a two line Javascript function stuck quietly in the HTML/JSP page. You can implement the whole thing in an hour.
It works through corporate firewalls, it works on laptops at Starbucks, it just works.

[Tim Holloway]

Nitpick time. I take exception to Pat's phrase "tomcat talks to a browser". Tomcat responds to a browser, but it won't (can't) say anything unless the browser said something first. HTTP doesn't permit it.

There's no point in installing Tomcat on each client. First of all, it complicates the client systems, secondly, the clients may be themselves firewall-blocked against requests. A lot of ISPs have Terms of Service that forbid hosting, so they sometimes block even ports 80 and 443.

If total connectivity via the open Internet is required, that pretty much limits you to AJAX polling of the server. Virtually no protocol is 100% guaranteed to be able to succeed in "pushing" data to clients, not even HTTP, for the reasons I just gave.

[Michael Oberleitner]

As i wrote in my second post, i implemented a swing application that communicates with a httpservlet (A), because later it should be possible to also implement a client which runs in the browser.

I don't know how to initiate a http communication from a http server with one or several clients and i think this is not possible, without a client request. That's why i wrote about installing tomcat on the clients, but finally that's not what i want to do and why i search for another way to communicate the changes in the db to the registered clients.

Maybe there is just a solution with polling, but this i is not what my customer wanted...

[Bear Bibeault]

I don't know how many more ways this can be said until you grok it: if the server is an HTTP server, the clients must poll. There is no way for an HTTP server to initiate communication with a client.

The only other alternative is hyper-expensive solutions like Comet (which holds the connection open for long periods).

[Jayesh A Lalwani]

Michael Oberleitner wrote:

Maybe there is just a solution with polling, but this i is not what my customer wanted...

Your customer is dictating design decisions?

[Bear Bibeault]

Jayesh A Lalwani wrote:Your customer is dictating design decisions?

I get what you are saying, but this has ramifications beyond internal design as the amount of generated HTTP traffic has consequences visible outside of the application. I think that client requirements regarding network usage are not inappropriate in this case.

That said, requirements that cannot be met aren't very helpful.

[Pat Farrell]

Michael Oberleitner wrote:Maybe there is just a solution with polling, but this i is not what my customer wanted...

Get a smarter customer. As described, you simply can't do it. AJAX or something like ajax is trivial and known to work.

This is not longer a thread about Tomcat, and changing to Glassfish, JBoss, etc. won't change any of the answers.

[Tim Holloway]

Michael Oberleitner wrote:
Maybe there is just a solution with polling, but this i is not what my customer wanted...

Customers want ponies and unicorns. They say "It's Easy! All You Have To Do Is..." And it goes downhill from there.

Well, all you have to do is replace the entire World Wide Web with one that has protocols that do what your customer wants. Every client and server on the planet. And in the International Space Station, too, if they have connectivity.

And while you're at it, can you repeal a couple of the laws of physics? I want my flying car and I want it to be able to run all day on 3 ounces of sugar water.

As you can see from preceding posts - and this one - we've spent too long in the business and have degenerated into a group of sour old curmudgeons. Comes from dealing with too many unrealistic expectations.

Sometimes the customer isn't always right.