im working on a project where i should transfer data from a c# server to an Java client (running on android device).
i need to use UDP protocol for a real time data and to maintain performance.
searching the web. didnt find any similar example and i really dont know where to start.
can you please suggest if this can be done ?
Thanks in advance.
Yes, it can be done. That's one of the beautiful things about the Internet protocols: support for standard sockets is so widespread and common that disparate devices running vastly different CPU architectures and software environments can interoperate with nearly no trouble.
Please make sure that UDP is really the best tool for the job. Do you need reliable delivery? Do you need in-order delivery? How much packetloss can you tolerate? How much packet re-ordering can you tolerate? Will your application handle 540 byte packets as gracefully as it will handle 1500 byte packets? Does your application need to protect against man in the middle attacks? How?
TCP is an incredible protocol. Many attempts to use UDP "for speed" wind up re-implementing many of the things that TCP provides for you already -- but most re-implementations are not done nearly as well as the real thing. Please don't be so quick to dismiss TCP.
To get started, just about any network tutorial for Java and C# should include something like a chat or echo server, the network programming equivalent of "Hello World". And that'd be good enough for a simple environment. If you intend for your server to handle dozens of clients simultaneously, it'll be more work, and if you intend for your server to scale into the hundreds or thousands, it'll be a different style of programming altogether.
Have you tried reading this:
http://nickstips.wordpress.com/2010/09/03/c-creating-and-sending-udp-packets/
The client is irrelevant, it can be Java, C++, or any other language/platform. Doesn't matter.
The protocol is still the same.
Hope this helps.
Try the Oracle Documentation as a starting point with UDPs, there you can find an example which i in java but as mentioned the idea of the protocols is to support a language independent communication.
Related
I am working on a project where i need to connect with multiple clients and every client is streaming live screen capturing to server. Server show that.
What would be the best approach for that.
Thank You
You can use WCF in streaming mode for the video, but I doubt it is a good solution.
I think that going for pure sockets is better, to get the performance required. Showing a live video stream is also not really a limited operation (which is what WCF is built for), but rather something ongoing.
My suggestiion is to:
Use a pure TCP socket for the video stream for a start.
If that gives problems, you can switch to UDP. It is better to skip over any lost packages for live video, but with UDP you have to track package ordering etc. yourself.
If you need control operations, use a separate WCF service for that.
Recently one of my machines was infected with malware using IRC to communicate back to it's command and control center.
This just sparked interest within me to see if there was a program I could create in C# that is capable of monitoring traffic over TCP that contains strings such as PONG / NICK / USER (strings the irc rfc needs to communicate), and then can tell me the process that that traffic is coming from.
It would be an interesting learning experience for me, and it's something that I want to attempt.
I've done some research and I found something that did make use of WinPcap but i think I'd like to avoid a solution using pcap if possible, can anyone send any suggestions my way?
I know I may be able to view connections between my computer and other hosts using System.Net.NetworkInformation.TcpConnectionInformation and possibly IPGlobalProperties but I'm not sure if there is anyway I can view the information in realtime, or easily trace it back to a process on my PC.
Thank you.
This is going to be hard. The API you need is native, Windows Filtering Platform (WFP). According to Microsoft, this is not accessible from C#, you would have to wrap it in C++/CLI first.
See here and here for discussion. The second thread has some 'could be useful' stuff for you.
I'm thinking like the methods games like Counter Sstrike, WoW etc uses. In CS you often have just like 50 ping, is there any way to send information to an online MySQL database at that speed?
Currently I'm using an online PHP script which my program requests, but this is really slow, because the program first has to send headers and post-information to it, and then retrieve the result as an ordinary webpage.
There really have to be any easier, faster way of doing this? I've heard about TCP/IP, is this what I should use here? Is it possible for it to connect to the database in a faster way than indirectly via the PHP script?
TCP/IP is made up of three protocols:
TCP
UDP
ICMP
ICMP is what you are using when you ping another computer on a network.
Games, like CounterStrike, don't care about what you previously did. So there's no requirement for completeness, to be able to reconstruct what you did (which is why competitors have to tape what they are doing). This is what UDP is used for - there's no guarantee that data is delivered or received. Which is why lag can be such a problem - you're already dead, you just didn't know it.
TCP guarantees that data is sent and received. Slower than UDP.
There are numerous things to be aware of to have a fast connection - less hops, etc.
Client-to-server for latency-critical stuff? Use non-blocking UDP.
For reliable stuff that can be a little slower, if you use TCP make sure you do so in a non-blocking fashion (select(), non-blocking send, etc.).
The big reason to use UDP is if you have time-sensitive data - if the position of a critter gets dropped, you're better off ignoring it and sending the next position packet rather than re-sending the last one.
And I don't think any high-performance game has each and every call resolve to a call to the database. It's more common to (if a database is even used) persist data occasionally, or at important events.
You're not going to implement Counterstrike or anything similar on top of http.
Most games like the ones you cite use UDP for this (one of the TCP/IP suite of protocols.) UDP is chosen over TCP for this application since it's lighter weight allowing for better performance and TCP's reliability features aren't necessary.
Keep in mind though, those games have standalone clients and servers usually written in C or C++. If your application is browser-based and you're trying to do this over HTTP then use a long-lived connection and strip back the headers as much as possible, including cookies. The Tornado framework may be of interest to you there. You may also want to look into HTML5 WebSockets however widespread support is still a fair way off.
If you are targeting a browser-based plugin like Flash, Java, SilverLight then you may be able to use UDP but I don't know enough about those platforms to confirm.
Edit:
Also worth mentioning: once your networking code and protocol is sufficiently optimized there are still things you can do to improve the experience for players with high pings.
I'm to trying to develop a program to transfer files using TCP (in a local network) with C#, files should be transfer in encrypted way.
My knowledge about c# is average, and about socket programming just know the basics.
Currently have no idea how to begin.It will be great if you have any suggestion about how to begin, if there is any book, website or any other resources.
You could use WCF with netTcpBinding.
This would encrypt the file during transfer and reduce the development effort, since you do not need to program any low level sockets code.
Unless you want to use it as a learning experience for C#/.NET socket programming, there are a lot of free FTP apis that will do it for you without the pain of having to reinvent the wheel. Indy has been going for almost a decade and the others are fairly stable.
TCP sockets are pretty easy to use. While I don't know the API in c#, it will undoubtedly support a send() method, where you can pass in the bytes of your file, and on the other side it will let you register a callback function that will be called when bytes are received. The TCP protocol guarantees that the data passed in-between will not be corrupted or lost. You will need to encrypt and decrypt the data yourself however.
The easiest way to begin is to code up a 2-client chat program where you send the messages using TCP. If you want to understand more about the TCP protocol and the "network stack" (a set of underlying protocols) then you can start on wikipedia and carry on with a decent book on networks - it is actually a very big topic, but you don't really need to know unless you are making a serious app.
By the way, an easy linux hack is to use netcat (type man nc to get help).
I would like to ask some advices or experiences from architecture or
technology for building real-time system. Before I have some
experience on developing "Queuing Management System", I have done by
sending TcpServer and TcpClient message to all operators when a
operator changed the queue number. But I think this strategy a lot
complicated and issues.
Could anyone guide me some ideas or frameworks?
First up: hardcore real-time peeps will take issue with the use of ".NET" and "real-time" in the same sentence, due to .NET's non-deterministic nature ;)
Having said that, if you're just implementing a supervisory or visualisation layer over an existing real-time system (say, implementing a SCADA-type system), then .NET should be fine. Then your network architecture can boil down to two scenarios:
Clients poll from a server: you create a centralised server which contains much of your process logic, and clients poll from this server periodically.
Server supports a publish/subscribe mechanism: clients subscribe to the server's information, and the server sends out updates when they occur.
There's no one "right" way to do the above comms; it depends a lot on size and frequency of updates, network traffic, etc.
I havent worked on anything real-time, but I would assume that looking into real-time linux would be a good start to understanding the problems and solutions they have come up with dealing with real-time applications.
I'd recommend looking at QNX.