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?
Related
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 6 years ago.
Improve this question
I am trying to write a service that provide user a subdomain as mailbox.
So I need to implement IMAP server on my own.
I notice mimekit/mailkit may help me. (At least they can help me test my server.)
It is possible to implement a minimum IMAP Protocol (server side) using mimekit/mailkit?
I would say that MimeKit would certainly be helpful in that a significant part of writing an IMAP server (or even a POP3 or SMTP server) is that you will at some point need to deal with parsing messages and/or headers and MimeKit is a perfect solution for that.
There are parts of MailKit which might be helpful for implementing an IMAP server. For example, re-using the UniqueId (and related) classes for your IMAP server project would likely be useful. Likewise, if you eventually implement the THREAD extension, the MessageThreader class would be invaluable.
The ImapEncoding class would certainly be reusable.
You might be able to at least partially re-use the ImapStream (and ImapToken) class as your tokenizer for an IMAP server, but I'm not 100% sure on that since I've never looked at it from that perspective and there might be subtle differences there, but you could probably use it as a reasonable starting point.
ImapUtils.FormatInternalDate() would be a good candidate for re-use...
You might be able to reuse a lot of the FolderQuota and AccessControl classes as well if you end up supporting the QUOTA and/or ACL IMAP extensions (not that those classes do much).
I'm sure there are various other bits & pieces that would be helpful to re-use from MailKit, but you won't be able to easily turn the ImapClient class into an ImapServer class, for example.
And then, of course, as you mentioned in your post, you could always use MailKit as a great way of testing your IMAP server implementation to make sure things work.
Hope that helps answer your question.
Is it possible to implement a minimum IMAP Server using mimekit/mailkit?
Short answer: No!
The main goal of this project is to provide the .NET world with
robust, fully featured and RFC-compliant SMTP, POP3, and IMAP client
implementations.
You should beware of the huge difference between a mail server (which keeps your emails, is visible to the outside world and normally is 24/7 live) and a mail client which is mainly used to fetch the mails from that sever.
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 6 years ago.
Improve this question
[C#] Hello all, I am curious on how I can go about creating my own local server and allowing people outside to connect an return data stored on it. I am not looking for an "XNA" solution. I would like to kind of digest the bare bones of client to server. Here is an outline for what I am looking for:
My PC
[Server] -> Constantly Updates/Receives Player data so it can be obtained by other PC's. Stores data from other clients.
[Client PC] -> Writes to server (Creates new player data/updates) and obtains further information to update visuals, other players, etc.
This isn't something small that anyone can just do, especially if you are just getting into programming. I would first start out small, make a few smaller applications, play around with the .NET framework libraries and get comfortable (I would specifically look at System.Net/System.Net.Sockets as well as possibly System.Security for SSL encryption). The networking component will be huge in this as you'll need to implement a system to handle the constant communication and be able to respond quickly (any lag can be seen as dropped packets from a networking standpoint and cause client time outs). You'll also want to think about what kind of data you are serving up (saved games, player data, whether it's personal information (such as passwords, email addresses, etc)) and how you are going to store that data. There are many paid and free technologies for this (Postgres, SQL, MySQL, etc). Please do a quick google on some of thee items I have mentioned and you'll see why it takes years to develop games and the back end systems to support multiplayer.
If you are the type of learner to plug things in and learn by tearing someone else's code apart, I would take a look at some of the articles below.
http://www.codeproject.com/Articles/1415/Introduction-to-TCP-client-server-in-C
http://csharp.net-informations.com/communications/csharp-multi-threaded-server-socket.htm
Here's some MSDN articles dissecting the different classes of the System.Net namespace and functions of it.
https://msdn.microsoft.com/en-us/library/system.net(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/system.net.sockets(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/system.security.cryptography(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate(v=vs.110).aspx
You'll also want to look at using threading to make sure the server isn't only processing one request at a time. There are many approaches to this but here is some basic examples of using threads.
http://www.dotnetperls.com/thread
When to use Multithread? (Some pointers how on and when to use threads on our very own S/O site :) ).
Here's the DL on threading from MSDN
https://msdn.microsoft.com/en-us/library/system.threading.thread(v=vs.110).aspx
Not meant to discourage you but more to show you the type of effort you'll have to put in to this sort of project. What you want to do is completely doable, but will require some brain training and head scratching. Apologies if it sound condescending, just trying to coach and am unsure of your level of expertise in c#! Best of luck to you though friend, hopefully this turns into a great learning experience!
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 4 years ago.
Improve this question
I want to start a simple windows P2P instant messenger in C#, similar to AOL, ICQ, etc, but much more simple (plain text messages between 2 guys)
I don't need examples on how to do it. I can find them myself.
What I do need is a general idea of how instant messaging works (P2P, not multichat) without many technical details.
For example:
Will I need a main server to make the communication between user1 and user2 happen or user1 can send the strings directly to user2? How is this called?
If user1 is logged in, how does he know of an incoming message from another user (or the online status of their friends)? Does the chat client app check every X seconds with a main server?
Any clues that might help me clear the general data flow idea will be very much appreciated.
A flowchart may also be helpful if you find one to share.
Thanks in advance.
UPDATE (NEW QUESTION) - July 6
Let's say the user had successfully logged in, and the app needs now to get and populate the list of contacts (saved on my apache/php/mysql server).
How would you implement the data retrieval (important) and later population of the contacts list? Is WebClient.DownloadString[Async] a good approach? Is there a better way?
How often should the app check for updated list (online/offline statuses). Recommendations accepted.
How can I parse JSON data on C#.NET (Visual C# Studio 2010)
I will get JSON strings.
Thanks!
If you really want to build a p2p app, there should be no server. However, this is not straightforward.
There are lots of different approaches to creating a chat system, mostly involving servers. Research comet (a good solution if implemented properly, terrible otherwise), polling (checking every x seconds) or using sockets, however there are lots of issues to be considered - and caveats, particularly firewalls/nat routers. A socket solution could potentially be 'p2p', but the polling and comet ones are not.
For your use case, I would go with a simple socket solution (one side as server, one as client) and configure your router firewall by opening a port at the server end.
You could extend this so that both sides could be both servers (listening on a port) and clients, so you could both 'call' each other.
You will need to have a permanent ip, or use a service like dyndns to get this to work properly.
Update
Yes, DownloadString or DownloadStringAsync would be a fine method.
How often is really up to you. I assume that this is only for a few users from what you said in the question, so you don't need to worry about overloading the server. Once a minute sounds reasonable, but once a second would proabably be fine too if you feel that way inclined... Parsing JSON in .NET answers your final query.
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