|
When you break your leg, does the hospital tell you it's all going tibia OK?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Let me set you straight: who knee'ds these puns? Do you get bone-us point for them?
By to-marrow, thigh Karma willist be most sorely diminished thereby !
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Aren't theses puns getting a bit sprained?
... such stuff as dreams are made on
|
|
|
|
|
Hmm, never thought to look at it from that ankle.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
That's a fibula.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
|
Nothing to do with Windows 10 or gin, but I checked and 'Technical discussions are encouraged' [in the lounge].
Say you have created a GUI and you want it to automatically update the screen when the data it displays changes (typically by an action somewhere else). Simplest way is probably polling, in which you regularly check back to see if any updates have happened. In a client/server set up, this has the disadvantages of lots of network traffic even when nothing's happening, and the latency of updates depends on the poll speed.
Then you have 'long polling', where you make a call to CheckForUpdates and it blocks until something happens or a duration elapses. This reduces the latency and network traffic but now you have blocked threads, which are much out of favour these days.
Then there are the 'Push' architectures generally using some sort of pub/sub paradigm and wholly embraced in such things as Rx. You subscribe to updates and then get notified of changes as they happen on a thread of some sort from somewhere. These are more complicated as you end up with state (subscriptions and their targets), queues, (producer producing faster than consumer consuming), and dispatching concerns.
So, what about an asynchronous long poll? This gives you the low latency, less traffic solution and by using separate threads for the outgoing and incoming packet, no threads get blocked client side. State information is client side (which I'd argue is good). The problem is you have to send the 'subscription' repeatedly to the server after each event.
When I think of it as messages on the wire, it seems like a good solution.
You look like a technically minded bunch. Any thoughts?
Regards,
Rob Philpott.
|
|
|
|
|
I think the server still needs some mechanism to track to-whom it is replying (and how)?
Definitely something to whiteboard or role-play around with to see how it might work?
|
|
|
|
|
I don't see much differences between "Long polling" and push notifications.
You will have a blocking thread on the client in both cases (wait for answer or wait for incoming push notification).
On the server you will have some kind of signal handling upon change events. With long polling it must then step through a list of pending poll requests. Similar for push notifications where a list of registered clients must be processed.
The drawback of the long polling method is that you have active connections for longer periods of time. This might be problematic for servers handling many clients (connection handles are a limited resource). It might be also necessary to handle specific events like informing the server when a client terminates (de-register in the term of push notifictaions).
To reduce the network trafic regardless of the method use UDP because there is usually no need for acknowledgments and missing a notification (which usually happens very rarely) should not care.
If the data change rate is not too high I would go for a simple UDP push solution:
Clients register at the server using a TCP command packet and start listening for UDP packets on a defined port. The server tracks the registered clients in a list and sends UDP notifications to each registered client upon change events.
If the clients are all located within a local network it is even simpler: Just send UDP broadcasts to the local net.
|
|
|
|
|
The only problem with this is that you have no way to tell if a UDP packet has been lost. Even if you do, you need a method of asking the server to retransmit the data.
Once you have done that, you might as well use TCP.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
It depends off course on the type of data and the requirements. A simple solution to this problem is using sequence numbers. Then a client can detect that he lost a notification and request a full update like when starting the client application.
|
|
|
|
|
Daniel Pfeffer wrote: Once you have done that, you might as well use TCP.
That is not really true. It takes considerable effort* to implement efficient message-sending over TCP, because it's the opposite of what TCP is for, it's for bulk transport. It hates latency and maximizes throughput. UDP + retransmits has no such problem, you don't get things like head-of-line blocking and exponential back-off (which are actively evil for a message-based protocol).
*: you can use a whole bunch (4-10) of TCP sockets in parallel and roughly round-robin the packets over the sockets (send it to some socket that has had its previous packet ACKed). Since a message is sent over a socket that is "empty" (no outstanding bytes to send) it mostly avoid congestion control nonsense, and at the receiving side there is nothing to block the message. Still has some annoying TCP-problems such as requiring an extra length field for every message, a lengthy connection procedure, and a billion open sockets on the server..
With UDP all you need is some keep-alives and a sequence number in every message so you can ask for retransmits. There is no inherent anti-latency bias to work around, it's a lot simpler to add a couple of things on top than it is to try to subtract.
|
|
|
|
|
I stand corrected 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Rob Philpott wrote: created a GUI and you want it to automatically update the screen when the data it displays changes
I'm only addressing this and my answer may be naive, but what you are talking about is easily solved with the technology at Firebase.com[^].
It's basically websocket technology and it is amazing. You can add it to your android, ios, web apps and much more.
If you've never tried it, I believe you'll find it amazing. 100s of users can see the changes made by any other user, instantly. Its a very small footprint. I wish I could explain it more fully here. It is amazing.
See It Live
Here is an example: pawns - move tokens[^]
When you move one of those pawns (game tokens) on the screen, every other user looking at that web site will see the pawn move. All done via Firebase.
Try it by opening up the page on your phone and desktop browser. Move a token in your destkop browser and you'll see it moving on your phone. 
|
|
|
|
|
All of the long polling solutions I've used are asynch on the client. Obviously it's going to be asynch on the server as well since you probably want to be able to handle multiple clients.
To my thinking, synchronous long polling is the same thing as a synchronous server call - no polling involved.
The way I understand it (this is definitely not my area of expertise) the difference between long polling and push is that in long polling the client is maintaining an active TCP connection to the server. In push notifications, the client is only maintaining an active connection to a local socket. In the former case, all of those connections are going through a variety of network hardware that might have their own ideas about the lifespan of a TCP connection. In the later case, the connection is only open long enough to send the data.
The server side code is going to be a lot more complicated in a push scenario, but these days most libraries will let you set long polling or push notifications as a configuration option during the connection setup, then the consumption of messages is the same regardless which communication protocol you chose.
|
|
|
|
|
My 2c: I prefer push, as the notification handling on the client is repeatable pattern, and it leaves all the rules up to the server for when to sending updates. The server can then make decisions like throttling notifications -- consider, for example, that each client might be looking at different data and different pages, which might have notification rules associated with them. Certain clients might be considered higher priority (like admins.) Whatever.
And besides, a good pub/sub pattern is the cat's meow. Especially if it's a semantic pub/sub, where subscribers subscribe based on what semantics they are interested in, not just a raw data stream. But that's me. 
Your concerns about push are of course quite legitimate, but again, because that is all handled on the server, it makes for a neater solution (and less Javascript, which should be, next to global warming control, the goal of the free world.)
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Rob Philpott wrote: what about an asynchronous long poll?
Works for me. I prefer to it to push because it's simpler (fewer dependencies between client and server).
/ravi
|
|
|
|
|
You hit the nail on the head with your general assessment here, but I'd say that you need to expand your analysis to a finer grain than application specific. In a given application/service/whatever there is some data that is best for polling and some best for pushing. You're going to have to make that call on a case by case basis. Best here being completely subjective because best could be long term code maintenance or performance.
From an architectural standpoint in enterprise development my recommendation is to use push based systems at the surface and behind the scenes implement polling that feeds into it via adapters if polling makes the most sense for individual messages/data/traffic.
For push based systems you have to determine what underlying transport/technology is best suited too. There's Azure Service Bus, Google Pub/Sub, ZeroMQ, Tibco, etc. Each is going to have it's environment. Tibco is popular in financial worlds because it's got a low latency UDP option. Azure Service Bus is super easy to implement and is durable/reliable messaging. Google Pub/Sub has support for huge volume able to handle 1 mil + messages per second.
Global Service Bus Architecture in C#[^]
Unified Message Bus Framework - Part 1[^]
|
|
|
|
|
UI? Whats that...
|
|
|
|
|
Push is evil and should be avoided.
Ideally, the clients should connect to a database and execute a query, but that doesn't always work -- it could put too heavy a load on the server or the query could take too long to execute, etc.
There was a system I wrote a few years back that had to feed about a half-dozen client systems with an extract of the state of the system. What I wound up doing was to have a Windows Service create and publish the extract as an XML file on the network -- e.g. Extract.0.xml , Extract.1.xml ... Extract.9.xml . I think a new extract was made about every fifteen seconds or so. The clients would connect to the database to get the name of the current file then read that file.
|
|
|
|
|
...because I dropped my gf off at the airport which is only 10 minutes from work. Since my direct manager has been out of the office for the whole week and didn't give me any specific tasks (the task estimated for 30 hours took about 6), I've been taking unpaid time off this week (which is fine with me, being a contractor, got lots of stuff done at home, wrote an article about Docker, spent yesterday doing fun stuff with my gf, etc) but here I am, still with nothing to do.
Checked my email. Nothing going on.
I'll probably just go home.
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Crash the server.
Then you can heroically come in really early and fix it. Instant brownie points! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
BCFH (Bastard Contractor From Hell)?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
PCFH (Practical Contractor From Hell)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Made that once.
Then could not fix it.
Painful moment.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
