I want to start writing games/applications with client-server architecture. I explored the internet and everyone tells that the best way is to use c# built-in socket libs. But If I am forced to write everything on my own (singletons, threads, keeping connection alive, parsing in-out messages etc.) I bet I will do it for months. Do you know any library supporting client-server based connections for C# (Forms/WPF/maybe Mono)? I can not find any "quite new" threads/information about this.
i think your problem will be, that you will not find an predefined lib which fits your requirements.
But if you write it with Visual Studio autocomplete will help you a lot.
However there are lots of question for me. What exactly is your target? What kind of game do you thinking of?
These factors affect your complexity of your "socket" enormous.
I think for a small "Ping Pong"-Multiplayer-Game your Socket is quite easy to do.
Related
I'm in the middle of the process of making an application on Windows in C# and I want to make an IOS and an Android program. Things are going well, but I'm kind of stuck on implementing the requirements for proper network communication.
I've searched a lot on sockets and I'm quite sure that I have to use that but I don't know for sure. I can't really find much about it. So I was wondering if you guys could point me in the right direction.
So my question basically is how to establish connection and send the proper functions.
You probably looking for an RMI Framework. (Remote Method Invocation)
What it basicly does is it's calling methods from other applications.
For example: on your pc you call rmi.DoDisPlayMessageOnPhone("Hello!")
your application on the phone will execute that method (you implemented -duh-).
It makes networking simple and you don't have to bother about networking that much.
Here is an RMI Framework that I use too:
SimpleClientServer (Scs)
It has a great example. Just read carefully and you will have networking in no-time :P
I'm working on project that will work real time: I have to write a video streaming client-server app, this server will to send the AVI/MPEG etc to an web application. I have some questions:
What is the protocol recommend to do this, http? rtp? or other?
In the web application, how do I to show it to user? using an flash player,java applet(I don't ensure if it's possible with it) or HTML5, what is the best way to do this currently?
I hope this is clean for you. Any help is very appreciadted. Thanks in advance. :)
There are several different ways to implement this (some that require programming and others that don't). Which one you choose depends on your requirements.
Red5 is an obvious solution which will allow you to only have to focus on the web side as long as your player of choice is flash.
FlourineFx provides a similar environment for .NET with a little more effort.
I've also done this with IIS and a custom server using HttpListener with much success if you're set on a pure Windows/C# solution. The caveat I'd add here is that it isn't always simple. In an environment with limited throughput, you will have problems since HTTP doesn't have the time corrections that RTP/RTMP/RTSP have but in a decent network it works 3 9's of the time (I've only tested with a single player though).
UPDATE
If you're talking about live streaming with .NET I'd suggest looking into the DirectShow (or related DirectX) API's. There is a wrapper for it for .NET available called DirectShow.NET.
Which programming language should I use to write an Instant Messenger?
Here are the goals:
should be able to handle many, many users (at least for proof of concept)
protocol should be based on json or maybe binary data. i guess json is easier to implement and extend. I don't want to use XML because of the overhead. I know it's not much data but it should be as fast as possible especially on slow networks (e.g. mobile).
users should be able to be logged in on multiple devices simultaneously
history should be saved server sided so it can be viewed on all devices
server should keep a lot of idle clients alive
file transfer (not quite sure on how to realize, maybe a different network socket so it does not block chat messages on client side)
MySQL auth
(No, XMPP is not an option).
I'm a web developer with good experience in PHP but that is not an option for this project. I also have experience with Javascript (mainly for websites), but it would be easy for me to work with node.js and I have little experience with C#.Net and could also write C#.Mono. The server I want to write should run on Linux. I have no experience with Java but if it's the best way I could learn it.
I've read much about node.js and that it's evented I/O is really good for network applications and web servers. But what about instant messengers? The main part is to save messages and proxy them to the other room participants, so it's "network".
I also thought about C# which offers asynchronous sockets which work with a thread pool afaik instead of a event queue.
I'm not sure which of them is most efficient in regard of an IM server.
It would be nice if someone could give me a hint. I know C++ would probably be the best way but I somehow don't really like that language and it's hard to learn.
You can do all this in any normal programming language (C#, Java, C++, etc...), as long as you're competent enough in that language.
Any of those solutions will do. You can write evented networking code in pretty much any language - and yes, it's pretty cool to use it in scenarios like this one.
If you want something that will give you some kind of framework for easier networking, I'd recommend trying Erlang, but it might be tough to learn for a single project. node.js might be tricky with regards to keepalives / resource management on dead connections and similar scenarios where you don't really get an event.
If you're already familiar with c#, using mono might be the safest / fastest thing for you. Apart from that - you can write anything in any language - just use what you're comfortable with (unless you actually want to learn something new).
I don't know why you wrote that jabber isn't an option, but if it's only the xmpp technology you don't want, why not use a typical SIP proxy/server? (for example OpenSIPS) It's got MESSAGE request handling, subscriptions, authorization (with db) and keepalives already available. You can scale / cluster / shard OpenSIPS in pretty much any way you want.
I've always wanted to learn TCP or UDP(I hear UDP sucks though) in C# but I can never find ANY tutorial that can teach it. I mean, I've googled tutorials to the point where the results aren't even relevant anymore. Almost every tutorial I've come across explains TCP as if I already knew it, or they introduce terms but never explain them. After a few months, I have made absolutely NO progress. Any help here?
Note: I am not a beginner programmer, I have experience making programs. It's just the TCP tutorials out there suck.
You're possibly searching with the wrong keywords. The keyword is sockets. The TCP/IP programming API is called sockets, on pretty much all platforms including .NET.
try codeproject.com
They have a lot of tutorials with pretty good code samples about TCP/UDP communication (among other things).
One of the many
I think it's difficult to find tutorials for TCP and UDP specifically because they are specific protocols (although very frequently used) and Microsoft are trying to abstract all these concepts so that your application is not dependent of the underlying technology.
Nowadays, you'll be advised to use Windows Communication Foundation (WCF); and you have a lot of resources from MSDN or the beginner's guide.
By the way, learning TCP cannot be done with a tutorial, but with a book focused on networking such as this one. If you do so, you'll also learn why UDP doesn't "suck"...
The reason there is no Cä# toutorial is because it is not needed. You basically ask "is there a course telling me how the rules are on streets when I drive a mercedes". Hint: there are the rules how to drive n streets, and theree is a manual for a mercedes car.
Or: There are books about the IP protocol, and then there is the .NET documentation how .NET implements this. If you ever want to be more than a junior in the field of programming then better get used to learn abstract concepts separate and do not expect a full "howto" for every simple step.
Now, TCP / UDP are fully separate items. They both extend TCP and they have very different uses. Saying "udp sucks" would be quite ignorant towards a lot of programs I know that would never work with TCP and require the fast and easy data distribution of UDP (which, cont´rary to TCP, also supports multicast). Most of my traffic counting in gb) external these days is UDP based because udp does not get stuck on a lost packet, and list packets can be easily requieried with a specialized higher level (application level) protocol. TCP has the really nasty habit of getting stuck up to 3 minutes when a packet is lost. Sometimes (like: financial data, voip) this is not really acceptable. Most programs love the easy handling of TCP, but it comes with a significant price.
UDP is a different beast.
however, I found this very useful as a starting point: TCP/IP tutorial
I've written some .NET-based TCP/IP posts on my blog.
They're not a tutorial; rather, they are a few articles on common mistakes. I'd recommend reading them after you understand the tutorials. I also list a couple of good TCP/IP books under the resources section.
I have a C++ application with data that needs to be shared with a C# application.
I'm currently transferring the data via files, but with speed and quantity of the data becoming an issue I would like to find a way to share the data through memory.
I'm a beginner to intermediate programmer at best, and so far I have heard of two methods that may be able to help me do this: Socket Programming & Memory Mapped Files
So my questions is, which is the best way to do this? (yes, speed is a factor)
and any info or links to info that could help me in my research and comprehension of the method you suggest would be very much appreciated.
Thank you,
You could use named pipes for interprocess communication. I haven't used it from c++ land yet though..
Sockets, IMO. It is standard, fast (even more so if you are running in the same machine) and very flexible. Memory mapped files I'm not sure if it is supported by C# but I could be wrong.
This is a fairly difficult question, mostly because there is no right answer. You definitely could use sockets or memory mapped files to communicate between two processes. Other alternatives are COM or simply posting a windows message from one process to another.
.NET - COM interoperability
Erm. I would suggest a different approach. I believe you would find it much easier to make an object (or objects) in managed C++. You can keep everything in your project native C++, except this file/class, which you would compile with /clr.
The /clr class will be able to interop trivially with .net, since it is .net. Then you can add regular C++ methods to the object to get data in and out as you see fit. Typically I would suggest copying data across the boundary so you don't need to screw around with pinning or anything.
It takes a little getting used to, but this approach is very flexible.
Here's a little something that talks about it better than I can: http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx
I'd probably suggest googling interprocess communication to do this. Each OS has a different method, but you basically need to signal one application from the other (with the signal encoding the data and datatypes).
Using sockets is a good method, but has the problem that if the loopback address of the machine is kaput (which can easily be done through mis-configuration while playing around with ip stuff) then your app won't be able to communicate. On a more serious note, if the loopback address is compromised and made to point at an attackers machine then your application is suddenly sending data to a malicious source, although this may or may not be a problem for you.
Memory mapped files aren't natively available in C#, but you could probably do something using P/Invoke.