Minimize network time to exchange messages with distant server

The situation I seek help with is this: A business on the east coast of the US, at random intervals, posts messages via the public internet to a set of listening subcontractors who subscribe to these messages. Each message announces availability of a unit of work to be subcontracted. The first subscriber who responds with an acceptance message indicating it has immediate capacity to perform the work is then awarded that work. One subcontractor is l开发者_运维百科ocated in the US midwest. Another on the US west coast. Due to the slightly longer time it takes for the messages to reach the west coast subcontractor via the internet, and for its responses to get back to the east coast, the west coast subcontractor's attempts to accept an offered unit of work are often too late (i.e. the nearer subcontractor has already signaled acceptance and been awarded the work) even though the west coast subcontractor also has capacity to do the work. I'm looking for the best way to improve transit time to overcome the distance disadvantage for the west coast subcontractor (connected to the internet via a T1 line). Any suggestions? (If this is the wrong forum for this question, suggestions for a better one would be welcomed.)

You will not be happy with the answer.

There is no actual way to improve the speed of your packets over the internet. If the passing routers are not under your control, there is just no way to reliably get more speed. The internet is based upon best-effort, which means, that no router guarantees that your packets arrive, neither when nor in which order. This is why TCP was invented. If you send two packets, you have a good chance that these two take two different routes to the destination. There is just no way to tell the routers inbetween you and the remote place to handle your packets prioritized or faster. There are some protocols that would theoretically speed up the packet transmission, but most of the headers are stripped on the way (in most cases, after the last router under your control.). There is QOS (Quality-of-Service) and the TCP Urgent header, but non of these really guarantee anything. You can try setting these headers and using these protocols, but there is just no way that you can tell, that your packets get prioritized.

I know that this is not satisfying in any way, but think about it the other way around. If packets were actually prioritized and handled faster on their flags, everyone would just set these, and everything would be as fast as now. You can try, but I can tell you, that most hops just blatantly ignore the flags.

Honestly, the only way to get there faster is to get a server physically close, and reduce network hops inbetween. If you can get a server in the same server center, great. On the same street, good. In the same city, ok. In the same country, also, ok. There will not be really another way to get there. The closer you can get physically and networkwise, the better.