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.
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 7 months ago.
Improve this question
I apologize for the multiple questions but I am having a hard time finding information on exactly what I am trying to do here.
Background:
I am working on a project that involves communicating with several server ports simultaneously that needs to somewhat scale. Some background on the project is I have a web application for users to pass commands to a console application. This console application will then send those commands to a specific port on a preexisting server through a tcp client.
My specific questions regard the console application communicating with the preexisting server.
My idea:
So my idea is to use a producer-many consumers thread scheme. I will need to be able to communicate with up to 300 different ports simultaneously and constantly through TCP connections. This console application will run as a windows service or something along those lines.
Question 1:
I am thinking of using a ConcurrentDictionary<string,ConcurrentQueue>() to track a queue of commands for every specific thread. Is there a better way to do this? I ask because I assume every thread would need access to the entire Dictionary of commands correct? Maybe this is a good approach but I have never done something like this.
Question 2:
Does spawning a single thread for each port I need to send commands to on the server make sense? The only reason I am thinking of doing this is because I will need to keep a TCP connection open for a very long time. The user can choose when to shut down the tool/connection. The only requirement really is this needs to be communicating for days at a time. The MOST I will reach is about 300 threads using this approach.
Question 3:
Obviously using an asynchronous approach is going to be necessary for this to scale well. Can anyone point me to some GOOD not out dated resources of the PROPER way to implement something like this asynchronously. I am willing to even pay for a book / online course if you have a good recommendation. The Microsoft docs are not very helpful because they do a scheme of 1 send and 1 read and then close the tcp connection.
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 8 years ago.
Improve this question
I'm not sure if I'm going to be able to explain it right since I'm quite sure I don't know the correct terminology involved with it, which is also why I'm having a difficult time Googling for answers.
Essentially, I'm looking to develop a program that serves as a web site. It'll run constantly (like a service) and will return HTML when an outside user sends an HTTP request thru a browser or similar to a specific port on the computer this program runs on. Basically, this program will perform various background errands throughout the day but I want to be able to expose a web front end (almost like how you would with standard WinForms, but I want to be able to access it remotely) to be able to configure it, check the status of tasks, and otherwise interact with it.
I'm looking to use .Net, but I'm open to using something more universal like Java too. Someone with experience in this area would be helpful to explain any pain points you've encountered and suggestions on how to get started.
You can do it in C# with the HttpListener class.
I published an example some time back. See A Simple Http Server.
Although you might consider whether you really want to operate at that low level. I have written a fairly complex server based on HttpListener, and if I had it to do over again I'd probably just bite the bullet and use ASP.NET. There is a bit of a learning curve, but unless your server is incredibly small and simple, an ASP.NET application will be a lot easier to write and will likely be more robust.
Here is a simple example on how to do it in C# using the HttpServer class:
http://www.codeproject.com/Articles/137979/Simple-HTTP-Server-in-C
You are doing at least 2 different things, so you should probably create a Solution in Visual Studio.NET with one project for each purpose (You can have many projects in a solution), probably with at least one Data Access project as well (of type Class Library). If the solution does things at certain times of the day, then those can be Console Applications that run through task scheduler, rather than one of more services. Services are better suited to things other than simple scheduled tasks. A Web Application project can serve up your html.
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 8 years ago.
Improve this question
I'm an beginner programer who is trying to have a list of objects stored on a server and clients can connect and view/edit this list.
I will try to explain as best I can what my set up is.
Server:
This will hold a "Main List" that contains all the objects of that list type. When a Client wants an update this list needs to be passed to the client so they can read it.
Client:
The clients will read the updated list from the server and when they make a change to the list this change needs to be sent to the server.
Right now I'm thinking I make it to where only 1 client can edit the list at any time, and since things can be added/remove/changed/location in list changed I think it would be best to just have the client send their list to the server to replace the servers. This way since only 1 will be editing the list the list should stay updated.
My problem is that I can't find a somewhat simple way to send a list of objects through the network. Currently I might be able to pull it off by taking one object at a time converting it to XML then back, but since it's a list that requires much much code. I'm hoping someone knows of an easier way to move a list of objects through the network or converting a list of objects to a string/back again.
An easy example of what I'm doing is imagine pictures on a field that people can click and move, so I need to keep track of the order of images, the x/y and the image name. That is a rough example.
Please let me know what you think, any help would be appreciated. I'm a beginner so I apologize for any incorrect terminology.
Thank you.
Text Protocol
XML
JSON
HTML/SOAP
XML works fine, especially if you're just learning. Its simple, and you've got enough to learn without worrying too much about efficiency at this point. Networking is a big subject!
JSON is a little less verbose than XML and equivalently as readable. I don't think C# has built in JSON serialization, so you'd need a third party library.
A web service would be easy. The information exchanged would be greater, but this would be more scalable as web servers are pretty optimized. However, I do not suggest creating a simple web service as it will teach you less than working directly with sockets.
Binary Protocol
Built in serialization
Third-party (Protobuf or Thrift)
Serialize by hand
If the data needs to be sent/received fast, or you are wanting a server that's more scalable I suggest a binary protocol. Binary protocols are small, and are difficult to read.
If all clients and servers are C# based, just use the built in serialization C# offers. It is more verbose than other serialization solutions, but its the easiest solution. Again, as you are learning, I suggest using built in serialization if you need a binary protocol.
If not all the clients and servers are C# based, use a library like Google Protobufs or Apache Thrift which offers a way to serialize objects in a binary protocol in different languages pretty easily and very efficiently.
Last solution would be to serialize by hand. It will be the very fast, but inflexible, difficult, tedious, and hard to maintain. I do not suggest it.
Don't send whole list back and forth. Send only updates.
Server should hold compiled list, and should also hold a list of all changes from the time whole list is 'snapshot' last time.
Updates are:
deletes
edits
additions
If you don't have much data, you can use simple xml for everything.
When received, every update should get serial number from the server. That way each client knows last update number and can request new updates if available by polling.
Upon connect, client should:
request snapshot from the server (receiving last ID snapshot-ed)
Later on, client should:
poll regularly for new updates and store that updates in local list
Upon any change on the client, client should:
pack the change and send it to the server
Implementing this will be both challenging and fun. And will surely create some more questions here :)