So I've got a project, running all on a private network. I've got a computer interfacing to some specific pieces of hardware and presenting a user interface via Winforms to control them all.
Now, I'd like the ability to split the app, such that all the interface and main business logic runs on one computer, but the GUI runs on another, connected via a network. There will be only one GUI running. The first impulse is, of course "use remote desktop", but there's high framerate video being displayed that won't quite work that way.
The video I can stream multiple ways, but what's the easiest way to communicate between a Winforms front-end and service back-end? .Net Remoting? WCF? Roll my own?
I would check out WCF as a first option. Using WCF makes it really easy and natural to split applications into services, and gives you the flexibility to change "bindings" easily to find a balance between performance and interoperability.
If you need high performance, check out the lower-level binary bindings like NetTcp.
WCF works quite well, but you might also want to check out the RemObjects SDK. That's pretty flexible. It has client and server components that you drop on the form/service and you can switch between a whole range of protocols just by change properties. There are versions for different platforms, if you need that.
http://www.remobjectssdk.com/net.aspx
I wouldn't roll my own unless I had very specific performance needs. Much better to use something where the hard work has been done already.
Related
I am creating a windows application in dotnet framework 4.5. The architecture involves a connection between Application and Central Server where it communicates to central server and sends data in case of a crash (a crash report is submitted). Also it downloads data from the server.
It's basically a two tier application. I am not sure which method will be best for the communication between these two as per the industry standards as well as acceptable to anti-virus applications.
So far, I have known about Socket communication as well as WCF but not sure if there are other methods or which one is better as per the requirements.
Please help.
Thanks!
Depends on the needs that you have, a web-service is always a good option, since it is very friendly for the network because it usually works in port 80 or 8080 and it has fail-safe mechanisms like exception handling which could make your job allot easier. If you use sockets, you might have problems, since the "network guys" will need to create rules for your application to work, and you still need to handle "manually" all of the connection problems.
I guess it depends on your needs, maybe give some more information so that you can get a more specific answer. In my opinion, I would say to go with the web-service since it is able to send binary data through the network in a safe way and it's more "scallable" (not sure if I translated this word correctly).
You can use both option with the WCF, but maybe you are looking for some other option? Is there any specific needs?
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.
How to create a NATIVE chat app for the iPhone? So far we have been exploring a few options:
Creating a web service using php or other web based language and have the app connect to that. Only problem is we can't figure out how to create "push" messaging with this, where the user will not have to refresh the conversation constantly.
Hosting an application on a server such as Windows Azure which will communicate to the iPhone app using TCP/IP. This way it seems like "push" messaging could be achieved by simply sending a packet to the iPhone. However, we have never done this before and don't know if we would run into any unforeseen potholes.
Have any of you made such an app before? If so how did you go about doing it? If not, what method would you recommend?
Thank you in advance!
EDIT:
To tell you exactly what we're trying to do: we need to make an app where a user can join a chat room and send/ receive messages from that chat room. There will also be custom features like that users will have their own profiles, etc. We would also like to make this as flexible as possible, so that we can integrate it on other platforms like android and blackberry later on.
So essentially the part that I'm stuck on is the send/ receive messages from a chat room. What technology should we use server side?
Something with an open socket, like Socket.IO could work. Node.js is a good server-side framework to explore. Here's an related SO question: iPhone Objective-C socket communication with Socket.IO
EDIT:
Question has changed since posting this answer -- originally question asked about web apps. ALso, originally the question was not clear that you wanted answers about the server side more than the client side.
On the server side, I would still recommend Node.js -- sounds like you want to use C# though, which makes me wonder why you're asking again about what server side tech to use. Most languages will provide you with ways to connect a socket to a client and access a database, which are the two main requirements of the app that it sounds like you want to make. Use whatever language you're comfortable with. However, some are going to come with libraries that may come in handy for this type of communication -- Node.js and Ruby on Rails (more useful if you want to do a polling-based solution)
Look at http://code.google.com/p/cocoaasyncsocket/ for a good library for doing socket communication from the iPhone without having to delve too deep into the low-level functions.
I've done this several times. Scaling to 100K concurrent users is non-trivial. If you want an off-the-shelf system I suspect ejabberd may do what you want. although the protocol IMHO is too verbose and uses far more bandwidth than necessary.
If you want to write your own solution and have the flexibility to write your own protocol and have the maximum possible scalability in the future then use a language that allows you to distribute the application across several servers. It is easier to allow that from the get go rather than writing a single server solution then have to retroactively make it distributable.
Having written servers like this in c++, Java and Erlang I would say the easiest and most relevant tool was Erlang. It makes good use of multi core processors and with a good design it facilitates distributing across several servers. C++ was the hardest!
I have also used Java with tools like JETTY and RabbitMQ to write a highly scalable system that required using HTTP as the protocol.
Personally I prefer a custom binary protocol as it allows you to reduce bandwidth to a minimum, and avoids DOS attacks and such as the protocol is well defined and lengths are sent before the packet, where as non binary protocols need to be parsed as they come in, with no idea of how big the packets may be.
Why not try XMPP protocol first? XMPP is based on TCP/IP.
There are several OpenSource server solution, clients, and application libraries. XMPP already supports chat room like service. You can define extension easily.
I'm writing a simple little game for my kids - it doesn't really matter what it does, though I couldn't tell you anyway, since I/they haven't quite decided yet! However, I think it will have a server component and a number of client components, and I'm looking at ways that the clients can communicate with the server.
ALL my previous experience... my entire career in fact... has involved the server element either being a database, a web server, or the two in tandem. Neither are appropriate in this case, so I'm curious as to what means I could & should use to communicate between the two.
Obviously, it would be preferable to adopt a technology or technique that I can re-use in my work, where I'm increasingly working with Windows Forms. I imagine there are 1001 different approaches I could adopt; it's a question of sorting the wheat from the chaff.
I've literally just started reading about WCF, but its unclear as yet, if this service-oriented approach is what I'm looking for.
I'm being deliberately vague about what the applications will do; I expect the client will announce their presence to the server, will feed user choices up to the server, and in return, the server will periodically update the client with what is going on in the wider game. The game will be turn-based rather than real-time... and quite low-tech really!
Suggestions? Ideally, with links to good learning resources if any are known.
Conclusion:
I actually thought there might be more viable alternatives; there is Remoting (now depracated), but the consensus says that WCF is the way to go - in my case, self-hosting looks appealing.
Thanks for the responses.
It looks like you're interested in WCF and that is a reasonable technology to use in this case.
When writing a network game the easiest approach is to use the client server approach here too. With WCF you have some different hosting possibilities, hosting in IIS or self hosting. I would go for self hosting to avoid the need for IIS on your home computers.
The service could be hosted in either a windows service or actually in one of the clients. I recommend running as a windows service. The service could very well run on one the same machine as one of the clients.
Edit:
If you want to host the server in one of the clients you could provide a menu option "start service" that starts a self hosted service on that computer (and automatically connect the client part to localhost). After the service has started you can present the computer name that you enter on the "other" computers to connect.
I would suggest to separate the service part into a separate project, then you can easily break out the service to a windows service later on if you like.
Edit2:
By the way, since WCF is driven by calls from the client you need to poll the server for changes. You can google wcf long polling or just long polling for methods to "push" messages from the server to the client.
Check out this article on creating a chat application using WCF -- http://www.codeproject.com/KB/IP/WCFWPFChatRoot.aspx
I've played around with this code in the past and the project was pretty simple to launch locally.
Here is a good book on WCF, which can help get you started. It has quite a bit of a learning curve (I still have barely scratched the surface myself), but I get the sense that it's a very powerful way to set up a service-based application. On the page I linked, check out the Examples link, which includes a bunch of code from the book, including Juval's ServiceModelEx, which has a wide variety of useful classes for working with WCF.
I'm going to go against the crowd here and suggestion NOT using WCF. WCF is a great technology for service oriented architecture, however it is largely written on the idea that clients will not stay connected to the server, but rather connect, send a message, perhaps receive a result, and disconnect.
There is a mechanism that can be used for long connected clients, but frankly, it doesn't work very well, has all kinds of issues and quirks, and is not very reliable in terms of knowing when clients have disconnected or not, or whether the clients know if they are still connected to the server. It's more of a bolted on solution that tries to shoehorn itself into the WCF model.
The other issue is one of firewalls. There can't be a firewall between the initiator and the receiver (or there must be an open port). That means you can't easily have two clients behind firewalls that want to talk to each other. You need some kind of exposed intermediate server that is open. While this problem applies to all solutions, it's easier to manage with straight TCP connections than WCF.
I'm not a huge proponent of rolling your own solution, but WCF really is overkill for simple two way communication between client apps.
I have not yet found a good open source network library for .NET. I know lots of people will chime in with various libraries, but every one i've seen is old and has various flaws. Most seem to be someone that ripped out their library from an app and tried to package it as a generic one, but leaving in all the assumptions of their app.
The problem is that recent versions of .NET have added lots of new network functionality, particularly in terms of asynchronous support. As of yet, i've not seen any libraries which implement these functions.
Anyone want to help me build a good, from scratch, network library based on .net 3.5+?
I would look at Remoting if I was you. It is fairly easy to impliment and you can definatly use it at work.
There is a tutorial on it here:
http://generally.wordpress.com/2007/05/31/a-simple-remoting-example-in-c/
I need to monitor several systems going thru stress testing. I want to make a client-server .NET(C#) application that will ping the systems to check temperature, memory usage etc.
The client will provide system info (cpu-mem-hdd configuration) at start then it will undergo through several benchmark/stress tests. The server will keep track of what is been executed and also will be able to detect system crashes. I pretty much have all the code for the client (have been running on the system, using WMI)
I have no experience with .NET remoting nor WCF, but I think this is a great opportunity to learn them.
What technology would you use?
WCF is meant to unify .net remoting with a handful of other Microsoft technologies. WCF gives you a lot of flexibility to change the design of your client-server architecture simply by changing a few .net attributes.
I recommend you proceed with caution and make sure you have a good WCF reference at hand. You will spend a lot of time spinning your wheels in the mud without one.
Snmp, maybe based on http://www.snmpsharpnet.com/.
Nothing fancy, new and shiny, but a protocol that is meant to be used for exactly the stuff you describe. Would definitely be my first choice.
If that is not an option for you: Second choice for me would be WCF, because that can be used from different platforms (you are more flexible in the future).
i will choose service bus.