Open Menu

Synergex Blog

Symphony Bridge

By Richard Morris, Posted on March 19, 2015 at 1:51 pm

For more than 30 years Synergex has enabled developers to take advantage of many different computer operating systems, hardware environments and networking topologies.  Today there are a number of different options to enable connectivity between client applications and services and the Synergy application logic and data.

If it’s a simple case of data on one machine and Synergy application on another then xfServer is the technology of choice.  One quick change to your environment variables and off you go – data being served on a plate.

If you want to move the execution of Synergy logic onto the server where the data is to improve performance while doing complex data searching and analysis, or need to access the application logic from non-Synergy environments like C#/ASP.NET/Java, then xfServerPlus is the perfect fit.  It takes a little more configuring, but is proven and reliable.

Both of these “server” technologies required a certain configuration of your network and are only recommended for use on your internal LAN.  So getting data and logic accessible to clients on the wrong side of your firewall, in a standard and secure way, requires the use of other tools or software.  The general approach is to create a web service to expose all the methods you would like the client to be able to consume.   Once you’ve written this web service you then need to run the Synergy application logic and data access.  You can call back into your traditional ELB’s via xfServerPlus or you could write the server in Synergy.Net and use xfServer to access the data – but stop!  If you do this you run the risk of running out of channels, different processes crashing your common data and other issues. 

Welcome to the Symphony Bridge Server and the Symphony Harmony namespace.  Symphony Bridge provides a RESTful web service layer that allows you to execute your native Synergy.Net application logic and data access from any Synergy supported client consumer.  The Symphony Harmony namespace provides the ability to access your applications database files using SQL syntax and to make remote procedure calls to execute Synergy application logic, without the need to build a web server of your own, because it uses the Symphony Bridge.

We’ll be presenting the new Symphony capabilities at DevPartner 2015 and you’ll get your chance to try them out by working through one of the self-paced tutorials.  You can also sign up for the post-conference workshop to utilise these new capabilities to build a complete client-server application end-to-end.

XP: The O’Hare of Computer Network Traffic

By synergexadmin, Posted on July 30, 2010 at 4:57 pm

Not long ago, I found myself with a lot of time to kill while sitting in an airport and waiting out a flight delay. The culprit, I was told, was a weather system circling over Chicago. At first this seemed odd, since the plane I was awaiting had neither originated in nor connected through O’Hare.

Chicago’s O’Hare Airport is one of the worst places you can find yourself when trying to make a connection. Whenever I see O’Hare on a flight itinerary, I immediately offer up the prayer: “ORD, have mercy.”

I’d intentionally avoided Chicago in my travel arrangements, so I was a little perturbed that O’Hare was still causing me a headache. I began musing on the ripple effect that it plays on the nation’s air traffic network, and a sudden thought occurred to me: “O’Hare does to the air travel network what XP does to data networks.”

I knew I was being unfair to Chicago, but hey: I was irritated. In reality, O’Hare is a well-oiled machine when compared to what Windows XP can do to a network. But thinking of the nation’s air traffic as a computer network really got my Analogy Engine started. I could see every plane as a network packet carrying bits and bytes of information. I saw traffic control towers as network controllers, and airports as individual computers (or hubs, as the case may be). I saw it all in a whole new light…and then wondered, “What would happen if an airport really handled network traffic in a manner similar to XP?”  It was a chilling thought.

For all of its apparent problems, O’Hare still has a significant networking advantage over the default operations of XP (and Windows 2000 and Server 2003): Selective Acknowledgements. The concept at the heart of SACKS allows the controllers at O’Hare to bring planes in for landings without regard for the order in which they were supposed to arrive.

If you’ve ever found yourself trying to diagnose why an XP user is complaining that “the Internet is slow” – even while everyone else on the network seems to be enjoying good speeds – then you’ve already seen what can happen when SACKS aren’t enabled for TCP communications. In fact, in this day and age, SACKS are so vital that it’s amazing Microsoft has never put out a fix on Windows Update – even as an optional one – that enables Selective Acknowledgements. Instead, they leave it up to systems administrators to manually edit the registry of each user’s machine – if, that is, they’re even aware of the problem or its solution.

I should warn you now that because I’m not interested in being the unwitting cause of a registry foul-up that destroys someone’s computer, I’m not going to tell you what those registry tweaks are. There are plenty of articles that will walk you through the process of enabling Selective Acknowledgement on Windows XP, as well as tips on setting the TCPWindowSize to further enhance performance. If you’re just reading this in hope of finding a quick fix to your XP networking woes, you might want to move along now.

On the other hand, if you’d like to learn a little more about SACKS and why it’s so important, then stick around and read on…

Understanding the importance of Selective Acknowledgments is perhaps easier if you understand what happens when they’re not enabled. Imagine that you’re Xavier Purdydumm (XP to your friends), and you’re the “receiving” traffic controller at Nitwit Sacksless Airport (airport code: NTSX)…

You arrive at work before a single plane has entered your airspace. You then review a list of scheduled arrivals for the day. You note the number of planes you expect today, and the order in which they will land. It looks like a light traffic day – you’re only expecting 25 planes before your shift ends.

You’re now ready, so you send out a notification that traffic operations can now commence. And look here! The first plane is on approach. So far, so good.

Plane One lands without incident, as do planes Two and Three. But oh-oh, now there’s a problem: Plane Five just landed…but where’s Plane Four?

You immediately send out a plane of your own. It’s instructions are to fly to Plane Four’s origination point, and to let its traffic controller know that Plane Four never arrived. In the meantime, Plane Six comes in, lands, and heads to the gate.

Still no plane FOUR. However, regulations are regulations so now you send out yet another plane to again request that plane FOUR be sent over. And aha! A new plane arrives. It’s….

…Plane Seven.

You repeat the process again and again, once for each time a new plane arrives. Finally, after you’ve sent off your 15th plane to request the location of the missing aircraft, plane Four suddenly lands. Turns out that plane Four got diverted when it ran into a storm system over Lake Cisco – the same storm system, as it turns out, that you just sent your last 15 planes flying into.

Well, that’s not your concern. You’re here to count planes coming in. And speaking of which, here comes another. It touches down, rolls past you and you see that it’s plane Five. You shake off a sense of déjà and cross it off your list.

You also cross plane Six off of your list – almost (but not quite) certain you’ve seen it before, too – when something odd happens: plane Four lands and taxis by.

Now how could that have happened? You’ve already crossed it off of your list, but there it is (again), plain as day. Deciding you must have made a mistake, you erase the check marks next to planes Five and Six, since there’s no way they could have landed if plane Four hadn’t landed yet.

And just to prove it: Here come planes Five, Six, and…Four?. Again??!?

By now, you’re completely confused, and the fact that one of your underlings keeps reporting that there are already planes sitting at Gates 4 through 6 is really getting on your nerves. He should clearly see that those planes haven’t been checked of your list, so why is he bugging you? You tell him to take care of it, as you’re very busy counting planes at the moment, so he tells them all to get lost. Taking a bit of initiative, he also shoos away the planes waiting to park at gates 7 through 18, too.

This process repeats itself again and again – a total of five times – before the count continues normally with planes Seven, Eight, Nine, Ten, and so forth. By the time plane Twenty Five successfully touches down and unloads at the gate, you feel that somehow your easy traffic day became a nightmare.

And it was a nightmare – but not just for poor Xavier Purdydumm. It was a grueling day for the traffic controller at the airport from which all twenty-five planes departed, as well as for everyone else using the air traffic network – including the folks that never even passed through NTSX.

Let’s take a quick look at the network traffic as shown in the above scenario, versus how it might have looked if Xavier had been able to work with Selective Acknowledgements:

Protocol Packets Received Total
No SACKS 1-2-3-5-6-7-8-9-10-11-12-13-14-15-16-17-18-4-
SACKS 1-2-3-5-6-7-8-9-10-11-12-13-14-15-16-17-18-4-


You’ll notice that the first 18 packets are identical, but after that things start to go awry. With only 25 packets in the total communication, a disruption on the 4th packet caused the network to carry 75% more traffic than would have been necessary had SACKS been enabled. Why?

Under TCP, it’s the duty of the receiver to notify the sender when a packet arrives out-of-order. Unfortunately, SACKS-less communications require that all traffic must arrive in order. And just to make matters worse, the originator of the traffic has its own set of rules to follow – the default of which being to only resend a packet if it has been requested in triplicate.

Now, in the example above, one might say that it was the storm over Lake Cisco that caused the issue, but it’s hard to blame the latency caused by the weather. Sure, it certainly caused the disappearance of the original “plane Four.” It also slowed down the traffic both to and from Nitwit Airport, thus allowing fifteen requests to be sent from NTSX before the originator ever received the first three and re-sent plane Four.

But note that the storm caused an equal number of duplicates to be dispatched, whether the protocol had SACKS enabled or not, so as a “factor” the weather pretty much washes out; everyone has to deal with it.

So while the weather causes things to slow down a bit (latency), the root problem is that SACKS-less communications require the sender to resend packets that have already been received in addition to the lost packet.. It’s bad enough in the tiny scenario shown above…but consider the impact if there had been 1,000 packets sent with multiple packet losses.

As I mentioned before, there’s a fix that allows you to turn on Selective Acknowledgements, but it’s not easy to implement – particularly if you’re a developer with multiple software installations at customer sites. The only way around the problem (and remember that it affects Windows 2000 and Server 2003 as well) is to modify the registry. You may find resistance from your customers when you tell that they’re going to need launch RegEdit and start adding DWORD values on every XP workstation they own.

For those of you who are wondering why SACKS-less networking is even in use on XP, remember that “Selective Acknowledgement” is a networking paradigm that came about long after the NT operating system had been created. Back then, when NT launched, there was no such thing as a “high-speed” internet. Networking technology was designed primarily to deal with LANs, which generally meant low-latency communications and fewer lost packets.

Years later, Windows 2000, Windows XP and Server 2003 were introduced. Everyone would probably agree that they were huge steps forward, but unfortunately they all borrowed heavily from NT networking services. That meant that they also adopted a SACKS-less networking default – even as internet speeds, overall network traffic and latency potentials were skyrocketing.

So the next time the skies are full over Chicago, the clouds are massing above Lake Michigan and you figure you’re either going to be late for dinner or late for your connection, remember Xavier Purdydumm…and thank the ORD for Selective Acknowledgements and the fact that O’Hare, at least, has made an effort to keep up with the times.


Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives