Lets say I have my C# app installed on 2 laptops connected to a WiFi Wireless Local Area Network.
How can these apps send messages to each other? What method or library can I use? I heard of using sockets but I have no idea how to work with these.
You could use WCF to build a communication pipe between the 2 applications. WCF encapsulates the sockets into a more manageable interface. You can start here.
Basically, you'll want to do it the same way you would in any other language. You'll open a network connection of one flavor or another (raw TCP or UDP, or a higher level protocol like HTTP) with one side acting as a server and the other acting as a client. Then each side can write data through or read data sent by the other side. It's can get pretty complicated from there. If you Google "C# Sockets" or "C# HTTP", etc, you'll find quite a few tutorials on the subject.
This is a very good article on sending C# objects (which could include whatever messages that you want to send) over a Socket connection using the Binary Formatter. Although it is not the most efficient, it is quite easy to grasp and get working.
Related
The project is to build a messaging mechanism between a Python and C# program via ZeroMQ .
I want messages to be able to travel in/out from both ends at any time, which is NOT a basic request-reply model a.k.a. REQ/REP.
One way I can think of is to build a PUB/SUB model on two ports, i.e. two one way channels.
Is there any method to get a real duplex channel?
There are several ways to do this with ZeroMQ. I suggest using a DEALER/ROUTER socket pair:
Choose one program to be the "server", the other the "client".
The server will bind a ROUTER socket on a port.
The client will connect a DEALER socket to the server's ROUTER port.
(Note: this implies that the client must know the server's IP and port in advance.)
At this point the client can send messages to the server, but the server has no way to send to the client.
The client sends a "HELLO" message to the server.
The server will receive a message that includes the client's address and the HELLO message. Now the server can send messages to the client using the client's address.
DEALER/ROUTER is considered an "advanced" socket pair in ZeroMQ. My description here is very high level. You'll really need to read the docs to get the most out of ZeroMQ.
Oh yes, Sir!
Use the PAIR-PAIR or even the XREQ-XREP ought make it.
The best next step is to carefully read the respective Scalable Formal Communication Pattern archetypes' access-points' API documentation, so as to cross-check, that all pieces of pre-wired behavioural logic meet your Project needs and voilá, harness them in your messaging setup and tune-up the settings so as to meet you performance and latency needs.
That is this simple ( thanks to all the genuine knowhow hidden in these builtins ).
Using for years this very sort of inter-platforms integration among Python + C/MQL4 and other computing nodes, so well worth one's time to learn the powers and strengths of ZeroMQ.
I'm trying to do some research on tcp client and tcp listener in c# for a microsoft exam. I've found quite a lot on the internet about how to use them, but very little about why I should use them.
I've discovered that it's a secure way of communicating between 2 applications, but I don't get why I should use tcp instead of (for example) just exposing a method on one application and calling it from the other.
Does anyone know of any good webpages that might be able to explain this to me?
If you are intending to communicate between applications with in a system you can use any inter process communication methods. But if you intend to have two applications running in different machines than you need a mechanism outside of IPC. This is where TCP and UDP come into picture.
TCP/UDP are elaborate protocols(rules) that govern how the two applications connect, exchange data and terminate the connection. (UDP , does not have the connect/terminating phase, BTW.)
Its interesting. Start with Wiki.
Most start socket programming with this well known page (In 'C' though) - http://beej.us/guide/bgnet/
I am writing a chat program between a server and a client in C# .Net. Both users, aside from chatting can engage in different activities like remote desktop and playing games together.
I have a few questions:
Multiple threads will be sending and receiving stuff from the client at the same time, that means every option need to identify which packet is meant for him and take data from it ? (Running a remote desktop while transferring a file a same time, the remote desktop thread will see the file packets arriving at stream but should ignore it, right?)
What's a good buffer size to set for the socket I will accept clients in?
Do I communicate in form of specialized class containing the data or try to keep the communication as a byte array I send over the stream?
The questions 2 and 3 are impossible for us to answer because we don't know what the communication and the requirements look like.
As for handling multiple threads: that is hard to get right, I'd use an existing solution.
I suggest you have a look at 0MQ as it might prevent you from reinventing the wheel.
There are .NET client libraries available: http://nzmq.codeplex.com/ and a nuget package http://www.nuget.org/packages/clrzmq/2.2.5 as well.
A good start is The Guide
For a quick example see this C# server and its hello world client in C#
I have the same dilemma as the one who posted this topic, Real-time communication with WCF
except that my problem is not about games programming. I would like to know what's the best method to use to be able to have a real time communication in between two windows applications (server-client). I am using visual c++/c# to date and i would like to be able to display all the Feeds that are being received by my server to the client in real time.
I have started trying to use .NET remoting but in my continuous research, it appears that it will use SOAP-http, and might affect the speed of the communication. My server and client will communicate using the internet and .NET remoting does not permit the use of TCP Channel when communicating in between a firewall or the internet.
Your inputs will be greatly appreciated.
I guess it depends on your escenario, if you want "real-time" and you are willing to lose some packages in the process you are better with UDP, take a video conferencing tool for example, by the time you recover your slow packages you will have to move and display the next frame in the video or audio; that is a good example for the use of UDP. This is the reason why UDP is much faster than TCP.
If however, you are not willing to lose a single bit of your message, then TCP was made for you because if you lost a package the protocol will request it again to have your complete message as complete as possible.
Additionally it depends on the way the communication is being sustained, is the information flowing from one to many?, from many to many?, one to tone?
Take NetNamedPipeBinding for instance, this will be much faster process, but is only deployed in a single machine but accross processes. Whereas NetMsmqBinding will help you to build queues and it will be amazingly reliable and scalable for scenarios where your load will be a massive number of connections.
In the end, it all boils down to your concrete escenario and your business goals.
Hope it helps
If you are willing to do your own message parsing, you can use standard TCP sockets with the TcpClient and TcpListener classes. If your data is already a serializable object, you could serialize it into a text stream and just send it over the socket, deserializing it on the client side.
To get it to work over the internet, the server needs to have the port forwarded on your router, the client would just attach to the server's public IP. You would obviously need to add an exception in your firewall for this port as well.
The biggest problem with WCF and large data is setting up the streaming, by default WCF sends everything at once, which isn't practical for large files.
I need to develop a client server system where I can have multiple clients communicating with one server at the same time. I want to communicate xml serialized objects and also need to send and receive other commands to invoke methods. Now, I am just starting with socket programming in C# and .Net and found that the asynchronous I/O is the way to go so that the methods dont block the execution of code. Also there are many examples of how to
make a simple client server system. So I have a basic understanding of how that works.
Anyway, what still is not clear to me is how I can set up a server which can manage connections to multiple clients?
Can I just create a new socket per connection and then store those in some kind of list?
Do I need some kind of multiplexing to achieve this?
Do I have to listen at multiple ports?
What`s the best way here?
And the other thing is if I need to develop my own protocol to differentiate between what I am actually sending over the network --> xml serialized object or a command which might be just a string encoded in ascII or something. Or would I develop my own protocol just to send these commands?
Any kind of help is apreciated! If someone knows a good book which covers this sort of stuff, let me know. Cheers
I forgot to mention that some of my clients which are supposed to communicate with my server will be pda and I therefore use the compact framework... So this might bring in some restrictions...
You may find several of my TCP/IP .NET FAQ entries helpful, particularly using a socket as a server socket, which explains how listening servers create new client connections, and XML over TCP/IP, which discusses the decisions you have to make for an XML-over-TCP/IP protocol.
I would abandon your plan to use Sockets and switch to WCF Windows Communication Foundation. It's far more elegant and is designed to do all the things you wanted, in a considerably easier and simpler way than .NET sockets.
If you want a guide of how to use it, there are a set of amazing Microsoft webcasts by Michele Leroux Bustamante that will have you up and running in no time.