I'm writing a multiple user server\client application.
Essentially, it will implement a chat room and allow users to communicate with each other. I've gotten the application to work between the server\client so far by sending a request to the server, which is always checking for an incoming network connection, and responding to it immidiately.
However, for the client to receive chat messages from the server, the only thing I can think of is running a server on the client. If I were to do this, however, the client would freeze up and not be able to do anything. Plus, the client is not designed for opening ports to connect to the server.
What would be the best recommendation on waiting on data from the server to come to the client, without causing the client to lock up?
Thanks!
(and also, I'm not a \professional\ c# programmer, more of an amateur, so please don't give me very complicated answers)
If I were you, I would use either a background worker, or a second thread. If you don't want to do that, you can use thread.suspend.
To start a new thread:
Using System.Threading;
Thread t = new Thread()
t.Start;
Note: this is not recommended.
Related
1- Client application sends a a request to an http server (ashx file, IHttpHandler).
Remark-1: Client is a .dll which will be hosted by other stand alone applications.
Remark-2: Server was first developed as a web service, then for unknown reasons it became very slow, so we implemented it from scratch.
2- Server registers the request in database so that a long duration process is performed on data.
3- Client needs to get notified when the process is finished.
First thing that crossed my mind was implementing a Timer in client. Although I'm not sure if it is ok to do it inside of a host application which is not aware of such usage.
Then it crossed my mind if there may be a something useful in TcpListener or lower layers of socket programming instead of a high frequency timer and flooding server with update requests.
So, I appreciate any suggestion on proper way of doing this task.
UPDATE:
After giving some order to my codes, I update requirements like this:
1- Server "Broadcast"s ID of clients, like: "Client-a, read your instructions", then "Client-c", "Clinet-j",... . This is not mission critical, if a client looses the broadcast, it will return after one minute by a timer tick and will check instructiosn.
2- This server is gona be hosted on a shared hosting plan, at least at first. Solution must be acceptable in boundary of share hosting.
3- preferably all clients connect to the only one socket. No usage of extra resources.
Any recommendation is appreciated.
Hi I'm wondering how to set up UDPClients to enable real-time 2 way communication between clients
I'm working on a simple network game in C#, it should be possible for a player to host a game and for others to connect to it
The host will send out the new game state every X millisecond and will simultaneously be receiving a continuous stream of user input from the other players
The other players will constantly be waiting for new input states and also be sending out user input to the host
What I'm wondering is how to achieve this.
Should I be using 2 different UDPClients, isn't there a potential thread conflict if they try to utilize the same resource at the same time? If not, do i need to set them up in some special way, else if I'm using 1 UDPClient, is there anything special i need to account for or is it thread safe and i can just fire away new messages while receiving?
UDP is a duplex protocol (like TCP).
You can safely send and receive off the UDPClient object at the same time. You should not use two UDPClient objects.
However, those operations do occur on separate threads (or pseudo-threads, if you use await/async), so you may run into synchronization issues in the calling code (obviously its hard to say without seeing it, but the potential is there).
I'm using MQTT Server TCP Connection to develop my Chat Application with Image Attachments.
The Text Chat is working fine but when comes to image attachments,the connection is getting lost and going to Application_Deactivated event.
I've tried connecting it back in the Application_Activated and Application_Launching Event,but even that doesn't work.
Is there any solution to maintain a TCP connection throughout the application background without loosing the Connection?
Actually while googling the solution, I came across Background Agents,is that going to work for me?If so,Can I get a perfect link for the tutorial?
The short answer is that you're not going to be able to maintain the TCP session when the user does something to leave your application (whether user backs out of the app or launches some other app). You should look into an API that the server supports to resume an existing user chat session over a new TCP session. I don't know MQTT to provide more specifics on how to achieve this magic. But once you figure it out, you'll want to use that mechanism to try to resume an existing chat session in both your Application_Launching and Application_Activated events.
A BackgroundAgent cannot run more often than every 30 minutes (except when debugging), that isn't frequent enough to keep a TCP session alive.
I am working on a Peer-to-Peer chat program but have ran across an issue: Running the client and server simultaneously. I do not want a dedicated server to manage connections. I believe the solution may be asynchronous direct connections, but I am not sure.
What I am trying to accomplish is to be able to run the program between two hosts, the program will be started and begin trying to connect to an ip address specified by a text box. At the same time, it will also start listening for incoming connections on the localhost ip address.
***I am using tcp, because on the off chance something is corrupted the message will not be able to be read (it is encrypted)
Issues:
1) It is conceivable a client could be waiting for a period of time before the other program tries to connect. So should some form of a loop must be utilized? If so, how?
2) I assume I need to use multi-threading, with one thread for the server part and one thread for the client part, but an issue is keeping them from hanging. Since both programs are identical there way be a way to listen and simultaneously attempt to connect to the other host.
3) I am also having trouble with making my server listen for connections to it, and do not know how to automatically have it pull the ip address from my computer.
Thanks for any help.
EDIT: This is on a LAN only.
Everything you need to know is in Microsoft's docs.
http://msdn.microsoft.com/en-us/library/w89fhyex.aspx
I have got an TCP Socket Application that client side sending huge string messages to server at same time.And server getting this messages writing them into Access DB.So if there are so many clients server side can not handle each client properly and sometime server closing itself.
Is there any way tell client's thread before send message wait for queue if there is another client currently in queue? With this server don't need to be handle for example 30 client's demand at same time.
For example;
Client sends message => Server processing 1 client's demand
Client is waiting for 1 client's demands for complete than 2 Client sends message => Server processing 1 client's demand
Client is waiting for 2 client's demands for complete.
My problem is appears when I use access db. While opening access connection saving data into tables and closing db is taking time and server go haywire :) If I don't use access db I can get huge messages with no problem.
Yes, you can do that however that s not the most efficient way of doing it. Your scheme is single threaded.
What you want to do is create a threadpool and accept messages from multiple clients and process them as seperate threads.
If that s too complicated. You can have a producer consumer queue within your server, all incoming messages will be stored in a queue while your server will be processing them first come first serve basis.
I think you should consider using a web server for your application, and replacing your protocol with HTTP. Instead of sending huge strings on a TCP stream, just POST the string to the server using your favorite HttpClient class.
By moving to HTTP you more or less solve all your performance issues. The web server already knows how to handle multiple long requests so you don't need to worry about that. Since you're sending big strings, the HTTP overhead is not going to affect your performance.