As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I plan on doing a little benchmarking around this question, myself. But I thought it would be good to get some initial feedback from "the community". Has anyone out there done any analysis regarding the pros and cons of these two technologies? My thoughts:
Opening and closing TCP/IP connections for web service calls is relatively expensive compared to persistent connections.
Dealing with intermittent connection errors and state, etc... would be easier with a web service based framework.
You don't see World of Warcraft using web services.
One question that I can't seem to find much of answer for anywhere (even on here)... are the limits on the # of persistent connections a single network card can support, etc?
This is a very generic question, and are multiple issues you raise explicitly, and many more issue correlated of which you may be or may not be aware.
One issue is HTTP vs. other protocols (or message exchange patterns, to be accurate). HTTP is request-response and many communication patterns don't fit a request response paradigm. A persisted connection allows for message oriented protocols that are more flexible, like a typical full duplex chat exchange pattern.
Since you mention WOW, they use UDP not TCP. TCP offers stream guarantee semantics, with order guarantee and no duplicates. But to achieve this a heavy price is payed in terms of latency. A game like WOW is much more interested in latency and does not care about order guarantee: latest packet is always the best and supersedes any previous packet information.
There are more issue lurking under the surface:
outbound firewall traversal (almost always allowed for HTTP)
invasive proxies that read and understand HTTP headers
inbound NAT traversal issues
And finally there is the issue you just ask about: TCP socket limits. They depends per OS. For example a typical out-of-the-box Windows Server will choke at around 1000 TCP sockets due to TCP port exhaustion. It has to be specifically tuned for higher numbers. Even tuned, it will hardly approach 64K open, functioning, sockets. For servers that need to connect to millions of clients the connections have to be multiplexed by mid-tiers and the messaging protocols have to be prepared with the issues that arise from forwarding, most importantly message order reversal.
This problem space is vast and there are many dragons under every bridge.
You are clubbing the format of message and mode of delivery together. If you have the kind of message where you economized the number of bits and rearranged pieces so the message can be consumed faster, Web Services is probably not the right choice for you. If I assume that you have relatively large text-based messages, Web Services may fit your needs. With that, this is how I will answer your thoughts:
Opening/Closing TCP connections: Yes, this is relatively expensive. Web Services rely on HTTP (and TCP/IP) to help out in the following ways:
If A single client has to send a lot of message, they will likely send them over a "keep-alive" HTTP connection.
You can place a load balancer in front of your web server that will further optimize the TCP layer. It will deal with the TCP/IP level chaos of connections and present only a handful of long term connections to your web server.
Dealing with intermittent connectons: HTTP being stateless makes this easier.
WoW with WS: I am not sure of the kind of messaging involved, but WoW needs to send out a flurry of extremely short messages, the HTTP header itself might be too much of an overhead to warrant Web Services.
I don't know the definitive answer to your last question. You will have one limit imposed by how many connections your web server can handle, then another one by your OS in the form of number of sockets.
Hope this helps.
-Raj
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Originally the team was thinking of developing a C# service for a parent company. The service would receive requests and then the service would ping a 3rd party and return the result.
Instead of it being synchronous, we decided we would have an AWS SQS and SNS queue for both requests and results. Our company would give credentials to our AWS for the parent to write and notify from a request queue.
Then this service wouldn't be a service, it would be a processor. It would then read from the queue and sent the requests and writeback the results to another SQS, SNS that would notify an API on the parent company side.
Question: Is this a good design? We are bypassing the use of services to prevent having to have retry logic and having to develop clients, rather we just communicate via queues.
There are many advantages to such an approach.
You allow your client and "processor" to focus on their
responsibilities and interact via a message bus
You allow the client and processor to be independent and decoupled of
each other, especially in terms of technology and programming
language used.
The can both be scaled independently as and when required.
If one of them is "down" then the messages can still be accumulated
on the message bus and won't get lost (assuming you have a suitable
TTL to cover this)
If the services offered grows, you can introduce new queues to
process them without impact the current client and processor
They are asynchronous
You can have multiple producers and/or consumers
Etc
There are of course disadvantages
Latency is increased. For some situations this is a issue
You are dependent upon a 3rd party product
If using AWS, Azure, etc, you are dependent upon a 3rd party company
Additional costs from 3pp party & product
Debugging can be more difficult
Tracing can be more difficult
Security can be more difficult
If a client or receiver goes down, it might not be immediately
obvious. Leading to a build up of messages, each of which might have
a limited time to live! (what happens if this occurs at the weekend?)
Acknowledging receipt of requests is difficult
Ensuring messages don't get lost when a process fails is more
difficult
Etc
You can of course find more about these on the internet.
So there is nothing wrong with this as an approach. The only question really is
"is this the right architecture for our use case(s)?"
Only you can determine this by weighing up the pros and cons, maybe together with your customer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm trying to set up a Windows service that can communicate asynchronously with a server, the idea is to transfer some strings. The format, well, it really doesn't matter that much.
So, in the local network, I'm cool, I even wrote a simple mobile app to test it with requests and it just works.
The problem is I now have to make it work from outside the network, and to make it happen I would have to forward the port from the router configuration, and that is really not an ideal scenario for deployment on user machines.
I've read that is the thing you normally use sockets for, but as far as I understand, at least with .NET, the server has to have the same framework (please correct me if that is not true), and in my case the server is not .NET.
Honestly, I don't know much about client-server interaction, and I have a huge conceptual blackout when reading the official Microsoft documentation, so scratch that. I've caught glimpses of WinSock and RPC from the docs, but a C# implementation feels like duct tape, and really a last resort.
That said, I reckon I need to make six questions:
Plain HTTP is a bad idea. Right?
Given the scenario, is sockets what I need? And if it is,
How can I implement that on the server? Also,
Is it better than using RPC?
How exactly does RPC work anyway? What do I need to read before the official docs?
What does a socket do to actually let the client receive an asynchronous call from outside the local network? (need it, I read it's possible)
Please forgive me if I am mixing concepts here, and thanks for reading.
NOTE to moderators: If this is a duplicate question in any way, or off topic, or invalid for any other reason, please help me first by pointing me in the right direction. I tried to give it a good search before posting, but since I am not so familiar with most concepts, I might have missed the one. Thanks!
Some answers here:
The problem is I now have to make it work from outside the network, and to make it happen I would have to forward the port from the router configuration, and that is really not an ideal scenario for deployment on user machines.
Portforwarding is only needed when connecting from outside the netwerk to a computer inside network (behind a router). So if a user machine connects to a computer directly on the internet, you don't need portforwarding. If a computer from the internet connects to a computer in your local network, you need to forward a port in your router. So it only affects your network.
I've read that is the thing you normally use sockets for, but as far as I understand, at least with .NET, the server has to have the same framework (please correct me if that is not true), and in my case the server is not .NET.
No, A socket from .NET can communicate with any implementation of socket from another language/platform. Only when communicating binary, you should be aware for endians.
Honestly, I don't know much about client-server interaction, and I have a huge conceptual blackout when reading the official Microsoft documentation, so scratch that. I've caught glimpses of WinSock and RPC from the docs, but a C# implementation feels like duct tape, and really a last resort.
In my opinion .NET has a solid base for handling sockets. There are many technics implemented. The async sockets are very scalable for many clients
That said, I reckon I need to make six questions:
_Plain HTTP is a bad idea. Right?__
Why would you consider Plain HTTP is bad? This is very usefull when the server is writting in other languages, like PHP/Python/ASP.NET anything that uses HTTP. If you're sending user private information, you should hash/encrypt it
Given the scenario, is sockets what I need? And if it is,
Depends on how to connect to the server..
How can I implement that on the server? Also,
Is it better than using RPC?
I only used RPC in form of WebServices, You can only use this, when de server has implemented it. There are some benefits to WebServices.
How exactly does RPC work anyway? What do I need to read before the official docs?
Read more here: https://msdn.microsoft.com/en-us/library/ms950421.aspx
What does a socket do to actually let the client receive an asynchronous call from outside the local network? (need it, I read it's possible)
There is no difference between communicating between inside and outside the network. Directly communicating via sockets is always asynchronous.
Regards,
You should use Websockets. I don't know why you saying that the server and client should have the same framework, this is not the case, I have used it with C# client with NodeJs backend.
https://msdn.microsoft.com/en-us/library/system.net.websockets.websocket(v=vs.110).aspx
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am currently working on a social networking application that needs to be highly scalable.
I have been reading about the publish/subscribe pattern(message bus) and am struggling with understanding proper use case scenarios - when this would be appropriate and when this would be overkill?
For example:
There are several areas of the site where users enter information on a form that needs to be saved to the database;
When the database saving occurs and an email notification(s) must be made to one or more users.
Also, for the save scenarios, I would like to give the user friendly messages letting them know their data is saved on the form after saving process completes, if I were to go pub/sub
approach.
How would I return success/fail messages back to the UI after a specific task completed?
Which scenarios are ideal candidates for pub/sub pattern? It seems to be overkill for basic form database saving.
From your two scenarios, the latter is a possible candidate of being implemented with a bus. The rule is - the more complex/longer processing takes, the higher probability is it won't scale when processed synchronously. Sometimes it is even the matter of not the number of concurrent requests but also the amount of memory each request consumes.
Suppose your server has 8GB of memory and you have 10 concurrent users each taking 50 megabytes of RAM. Your server handles this easily. However, suddenly, when more users come, the processing time doesn't scale linearly. This is because concurrent requests will involve virtual memory which is a hell lot slower than the physical memory.
And this is where the bus comes into play. Bus let's you throtle concurrent requests by queuing them. Your subscribers take requests and handle them one by one but because the number of subscribers is fixed, you have the control over the resource usage.
Sending emails, what else? Well, for example we queue all requests that involve reporting / document generation. We have observed that some specific documents are generated in short specific time spans (for example: accounting reports at the end of each month) and because a lot of data is processed, we usually had a complete paralysis of our servers.
Instead, having a queue only means that users have to wait for their documents a little longer but the responsiveness of the server farm is under control.
Answering your second question: because of the asynchronous and detached nature of processed implemented with message busses, you usually make the UI actively ask whether or not the processing is done. It is not the server that pushses the processing status to the UI but rather, the UI asks and asks and asks and suddenly it learns that the processing is complete. This scales well while maintaining a two-way connection to push the notification back to the client can be expensive in case of large number of users.
I suppose there is no definite answer to your question. IMHO, nobody can evaluate the performance of a design pattern. Perhaps, someone could consider comparing it with another design pattern but even then the comparison would be at least unsafe. The performance has to do with the actual implementation which could vary between different implementations of the same design pattern. If you want to evaluate the performance of a software module, you have to build it and then profile it. As Steve McConell in his legendary book suggests, make no decisions regarding performance without profiling.
Regarding the specific pattern and your scenarios, I would suggest to avoid using it. Publish-subscribe pattern is typically used when the subscribers do not want to receive all messages published, but rather some of them satisfying some specific criteria (eg belonging to a specific kind of messages). Therefore, I would not suggest using it for your scenarios.
I would also suggest looking at the Observer pattern. I suppose you could find many more references online.
Hope I helped!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
This is a common question, but Googling this gives a lot of crap.
As data volumes are getting higher and higher, all along with processing power & cloud capabilities, we are witnessing a growing need for fast data transfer technologies capable of unleashing the power of all this available data by spreading / moving / sharing it across different servers/clients.
In our case, we are recording real time binary data (50 Gigs a day) and we need to upload it / download it every day to/from subscribers (yes, all of it is needed locally by each subscriber server, for computing and various data analysis stuff)
So to put is shortly, what are choices available today to transfer many Gigs of Data REALLY FAST between remote windows servers (VPS's, Cloud, with a "fairly" consistent bandwitdth -(optic fiber put aside) )
This is an open question. Every Idea is welcome whatever the protocol.
The challenge of sending and receiving the data over the network is multi-fold.
The network bandwidth is the most limiting factor and there is hardly anything you can do for this at application level (except occasional compress the data and even in that case the compression ration determines the gain). So faster network is the first choice.
Certain protocols are more suited for transferring certain type of files/data. For example http is a text based protocol and and not really suited for binary and large contents. But since its the most popular web protocol which needs binary contents to be sent over the wire, techniques like encoding and chunking have evolved. HTTP is really not the choice if your data is in the order of GBs which is your case.
FTP is the most popular protocol used to transfer files over the network and its specifically designed for transferring files. There are several extension of FTP like GridFTP, bbftp which are very specifically designed for large data transfers.
BitTorrents is another option that can be explored. Facebook uses BitTorrents to push the binaries to the servers (tens of thousands in number).
You problem is very open ended and I am limited by my experience :). Here is link I found which deals of large data transfers. Hope this helps you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Overview
I am sending messages back and forth between a client (Android phone) and a Server (Windows Server). Using a persistent connection over TCP, which protocol would be the best solution. I am looking at performance, scalability, size of messages, and battery life. The messages must arrive at the destination in order and can not be duplicates.
MQTT
This seems like the better solution, but there seems to be little examples of large implementation with lots of users. I am not sure if I can integrate this into the windows server, or if it would have to be another application or server running. Finally there seems to be a lack of information on it in general.
XMPP
This seems to have lots of implementation, examples, and even a book : ). However the main purpose seems to be for instant messaging clients and things like Google talk. Will this be an optimal solution to messaging between server and client. I know currently XMPP is mostly used in client to server to client architectures.
Please correct me if I am wrong and thanks in advance for any guidance.
It depends on what you are trying to do and what hardware you are running.
MQTT has very low keep-alive traffic. XMPP is a an IM protocol, and has a much, much higher overhead in handling presence messages between all the clients.
If you have a small memory footprint constraint, then having to handle the XML parser may make the use of XMPP impossible.
Keep in mind that MQTT stands for Message Queue Telemetry Transport, i.e., it is a transport protocol and does not define the message format at all - you will have to supply this; XMPP is an Instant Messaging protocol which carefully defines all the message formats and requires that all messages be in XML.
In addition to all this: MQTT is a publish subscribe protocol, XMPP is an instant messaging protocol that can be extended (using XEP-0060) to support publish subscribe. You need to consider this when you architect your system.
We are finding MQTT to be the quiet achiever. Your milage might be different.
It all depends ...
Track down the recent announcement by LinkedIn where they discuss their use of MQTT in their mobile app.
Cheers
Mark
(BTW Andy was slightly off in his reference to us. We are at Centre for Educational Innovation & Technology (CEIT), The University of Queensland, Brisbane, Australia)
I think that in short the MQTT advantages over XMPP are:
Throughput capacity: less overhead, more lightweight
Binary vs plain text
QoS in place (Fire-and-forget, At-least-once and Exactly-once)
Pub/Sub in place (XMPP requires extension XEP- 0060)
No need for an XML parser
I think you are probably correcting your assessment of XMPP in that it is a primarily chat-oriented protocol - it is also quite heavyweight and uses XML extensively making it verbose. I know that folks at CEIT at the Uni of Brisbane have specifically studied the differences and optimal uses for the two protocols. MQTT is very lightweight and low power - it has been used for telemetry and sensor applications for over 10 years and has been deployed on a very large scale by IBM and partners. Folks are now finding that a simple protocol like this is ideal for mobile development.
What exactly are you looking to achieve? The mqtt.org site aims to provide good links to content. There are also IRC channels and mailing lists about it. How can we help?