For a project I have to make an application that runs in a network. In this network there are 2 or more clients(streamsockets) connected to 1 server(streamsocketlistener). Is there a way to tell the server to receive data from one client and then sending it to the other client, instead of staying on the same connection?
Do you mean as in relay the data from one client to another via a third (i.e. server)? If so then this WPF client server chat example article demonstrates that. In particular see the comments within a method called HandleIncomingChatMessage, about half way down that article.
Related
so here is my goal
ther's this applications which we wrote (we being me and my team),and then we decided that the app needs some sort of online support.
the application is written in c# and uses SQL as db,and the app has Dongles.
im trying to develop online and offline ticket methods,however the problem showed up when i realized the chat has to be refreshed...i.e the message that the admin panel sends to the user has to somehow tell the user to refresh the ui and get the data from the online server itself...if the client had static ip address,that would have worked fine,but with no static ip address the only solution i can think of is to write a timer in every client and tell it to refresh the data every x seconds,which isnt a good method in my opinion.
so
TLDR : is there a way to refresh the data without writing timers?like can the server access the client without that?
You can use longpooling strategy.
https://en.wikipedia.org/wiki/Push_technology#Long_polling
Or if you're using only sql server - you can use SQL Server Notification Services
Also you can use SqlDependency if you use LINQ to SQL. The simpliest way described there dunnry.com/blog/UsingSQLDependencyObjectsWithLINQ.aspx
TLDR : is there a way to refresh the data without writing timers?like can the server access the client without that?
No, the server can't initiate a connection to a client. The client can be behind a firewall or a NAT for example. You can have the client poll for updates, or you can have an open connection (initiated by the client) where the server can notify of updates.
My client sends messages to the my server using tcp protocol (my server has a listener).
I'm trying to send messages back from the server to the client, but I'm not sure what do I need to add to the client in order to get those messages.
I tried looking it up, but I didn't understand how to implement it.
Could you please assist?
It's the exact same process, but in reverse.
If you intend to receive messages independently (i.e. not in response to a request by the client), you need to make the client a TCP server, too. The client needs to implement exactly the same thing as the server you have now and the server needs to connect to the client.
Can't you use WCF, which supports callback contracts?
If you want a console example of a client server application using a network library see here http://www.networkcomms.net/how-to-create-a-client-server-application-in-minutes/.
If you want a WPF application example then see here http://www.networkcomms.net/creating-a-wpf-chat-client-server-application/
I have a C# applications which acts like a client and it can be installed on any system which is directly connected to public internet (through data cards or port forwarding) or they can be behind router also (without port forwarding).
The other application which is developed using java acts like a server application which is on the public internet. Now, my java application wants to push a message to C# application which is behind router. Java application has the clients public and private (192.168.x.x) IP address. Java application is supposed to run 24x7.
So, now there are two options for me:
Whenever c# application starts it will establish a socket connection with java application and this socket connection will remain open till C# application gets closed.
Whenever Java application has something for C# application it will create a socket connection with C# application then it will push the message and then close the connection.
Now, with 1st option there is a problem that there will be lots of unnecessary connection since there can be thousands of client application and it may happen that on some day there will be nothing to push for some clients. and I don't know how to go for 2nd option.
What will be the right way to accomplish this task (option 1 or 2)?
Is UPnP protocol right for 2nd option? What are the open source UPnP libraries which has both the API's (C# and Java). I found one such called ohnet. Will it be a right thing for me? I didn't found a single small example for OhNet to test.
2) is not feasible if you don't have control over network configuration at the client end. It won't in general be possible for the server to make connections to the client if the client is behind any moderately secure firewall / router.
So you will in general have have to go for some variant of 1) where the client creates a connection to the server.
You don't necessarily have to keep the connection open though - it's always possible to get the client to poll the server periodically to check if there are any new updates.
If you want realtime updates to the client from the server then you will still need to keep a connection open. This isn't necessarily a problem if you use Java NIO you should be able to handle tens of thousands of simultaneous incoming connections relatively easily.
Using option 2, will you have to queue messages for your C# client until it connects? That could make your Java application run into out of memory problems if the C# application doesn't connect.
I would definitely use method 2 by adding a static route in the router (port forward). You should - however - ensure that the server behind the router is protected from the rest of your network (DMZ).
UPDATE:
Perhaps I have missed something here (method 1 or 2) :-) - but just to make it absolutely clear: It is always the client that should initiate the connection to the server. And yes, you could allow the client to request the server for updates on a regular basis.
This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.
I have a server process bound to a port that receives network packets at essentially random intervals. When a packet is received it is parsed and an object representing this packet's data is created. I would like to be able to 'push' this data object to any number, 0..n, client processes running on the same machine. The clients will always be on the localhost.
A client process is only interested in data objects created and pushed by the server since it was launched. This is also a one-way only flow of information. Client's do not need to communicate with the server they just need to receive any new data objects from the server.
The server and client processes are both written in C# using the .Net framework.
Given this setup, what method of IPC would you use to get this to work? My current plan is to serialize the data object and write it to a named pipe that clients read from. Is this the way to go? Also worth noting is that speed isn't a critical factor.
I solved this using WCF callbacks. Clients 'subscribe' to the server, the server then iterates over the subscribed callbacks and calls them with the data to be pushed. When a client process is ended it issues an unsubscribe.
There are loads of examples of this on the net that are fairly easy to follow. For anyone interested these links might help.
http://msdn.microsoft.com/en-us/magazine/cc163537.aspx
http://dotnetaddict.dotnetdevelopersjournal.com/wcf_alarmclock.htm
http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx