Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
I apologize for the multiple questions but I am having a hard time finding information on exactly what I am trying to do here.
Background:
I am working on a project that involves communicating with several server ports simultaneously that needs to somewhat scale. Some background on the project is I have a web application for users to pass commands to a console application. This console application will then send those commands to a specific port on a preexisting server through a tcp client.
My specific questions regard the console application communicating with the preexisting server.
My idea:
So my idea is to use a producer-many consumers thread scheme. I will need to be able to communicate with up to 300 different ports simultaneously and constantly through TCP connections. This console application will run as a windows service or something along those lines.
Question 1:
I am thinking of using a ConcurrentDictionary<string,ConcurrentQueue>() to track a queue of commands for every specific thread. Is there a better way to do this? I ask because I assume every thread would need access to the entire Dictionary of commands correct? Maybe this is a good approach but I have never done something like this.
Question 2:
Does spawning a single thread for each port I need to send commands to on the server make sense? The only reason I am thinking of doing this is because I will need to keep a TCP connection open for a very long time. The user can choose when to shut down the tool/connection. The only requirement really is this needs to be communicating for days at a time. The MOST I will reach is about 300 threads using this approach.
Question 3:
Obviously using an asynchronous approach is going to be necessary for this to scale well. Can anyone point me to some GOOD not out dated resources of the PROPER way to implement something like this asynchronously. I am willing to even pay for a book / online course if you have a good recommendation. The Microsoft docs are not very helpful because they do a scheme of 1 send and 1 read and then close the tcp connection.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is there a way to call a function to run on all instances of a Windows Forms application across a LAN?
I have an application which contains a dashboard of their own Joblist. I want another user on another PC to create and allocate a job to this user. Once created and saved, I would like the method GetJobs(); to refresh. I've not done anything this advanced yet, so please go easy :)
Chris Walsh has excellent advice in his comment. That said, it is possible for Windows Forms applications to communicate with each other, and the simplest method, for me anyway, is WCF, self-hosted server. Typically the server code will not be running in the UI thread -- at least I don't recommend it. In fact, all WCF is best kept running in a background thread in a Windows Forms application, to avoid blocking the UI. WCF has lots of error conditions you will need to handle.
Another thing you might want to look at is MSMQ, now called Message Queueing. It can store a queue of jobs for you, and it won't lose them if the power is lost.
I assume you have some SQL Server Express Edition installed as the database backend.
This way you can connect to the database using some authentication, and add the job's directly there.
Then on the other computer, add a refresh button or poll for changes. This has the advantage that you don't need to write a service by yourself, and jobs can be created even if the user is not there and his PC is switched off.
You need just one server which hosts the database.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Trying to make console app that monitors alongside its main program, and monitors what the main program has going in and what goes out its tcp/ip sockets. I have seen people do this in a few programs, but I can't figure out how. Something about using a raw socket, but I am not sure.
Any ideas how?
If you want the console app to be entirely separate from the main program, you can do this various ways:
Create a man-in-the-middle proxy for the connections. Run a client and server socket from your console application - i.e. clients connect to your proxy server and then your proxy server will forward the connection to your main program. This allows you to record the packets on their way through your console.
Hook winsock.dll. Essentially you will be gaining access to the parameters of send() and recv() calls that your main program makes, and you can then output or do as you like with it.
Forget programming it, and use Wireshark or another network sniffer to check what's going in or out.
More information on number 2:
It was surprisingly difficult to find good tutorials in C#, mainly because it's generally done with C++ or C. Some links to get you started:
https://en.wikipedia.org/wiki/Hooking
http://csns.calstatela.edu/download.html?fileId=2062150
http://www.elitepvpers.com/forum/co2-programming/1917917-c-dll-injecting-hooking.html
A tool to assist with hooking: http://easyhook.codeplex.com
I'll update this list as I find better resources. I might make a tutorial myself, will keep you informed.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm designing a program that uses a third party electrical solver.
I want to perform monte carlo simulations on large electrical grids and most of the times the program (mine) takes hours.
Because of this I thought that if I create a client in other computer I could call from my computer (and vice versa) I would have a nice distributed simulator.
Since I lack the knowlwdge, I would like to know what is the best way (if even possible) to "invoque" a program installed in another computer in the local network to do a specific task: simulate a file that I send and return the results back. The idea is to call the solver in lets say 10 computers at a time and gather the results asynchronically.
The language I use is C#.
I hope that my question is clear enough.
The easiest is to have a shared drive on the network, to which all computers have access. Then your app saves the input file (or one input file per machine, depends how you want to do it) on the shared drive, and your app starts another app remotely on each client. It monitors each one it starts for the exit status. After all of them have exited, it takes the output files and combines them and processes the data. Job done. The simplest "remote process" invocation is probably through psexec which you can download from technet, we have used it very successfully and very simple to use. The top two answers of How to execute process on remote machine, in C# have other good ideas: I think you will find them more overhead (longer to implement) but will give you more power in the long run.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I want to start a simple windows P2P instant messenger in C#, similar to AOL, ICQ, etc, but much more simple (plain text messages between 2 guys)
I don't need examples on how to do it. I can find them myself.
What I do need is a general idea of how instant messaging works (P2P, not multichat) without many technical details.
For example:
Will I need a main server to make the communication between user1 and user2 happen or user1 can send the strings directly to user2? How is this called?
If user1 is logged in, how does he know of an incoming message from another user (or the online status of their friends)? Does the chat client app check every X seconds with a main server?
Any clues that might help me clear the general data flow idea will be very much appreciated.
A flowchart may also be helpful if you find one to share.
Thanks in advance.
UPDATE (NEW QUESTION) - July 6
Let's say the user had successfully logged in, and the app needs now to get and populate the list of contacts (saved on my apache/php/mysql server).
How would you implement the data retrieval (important) and later population of the contacts list? Is WebClient.DownloadString[Async] a good approach? Is there a better way?
How often should the app check for updated list (online/offline statuses). Recommendations accepted.
How can I parse JSON data on C#.NET (Visual C# Studio 2010)
I will get JSON strings.
Thanks!
If you really want to build a p2p app, there should be no server. However, this is not straightforward.
There are lots of different approaches to creating a chat system, mostly involving servers. Research comet (a good solution if implemented properly, terrible otherwise), polling (checking every x seconds) or using sockets, however there are lots of issues to be considered - and caveats, particularly firewalls/nat routers. A socket solution could potentially be 'p2p', but the polling and comet ones are not.
For your use case, I would go with a simple socket solution (one side as server, one as client) and configure your router firewall by opening a port at the server end.
You could extend this so that both sides could be both servers (listening on a port) and clients, so you could both 'call' each other.
You will need to have a permanent ip, or use a service like dyndns to get this to work properly.
Update
Yes, DownloadString or DownloadStringAsync would be a fine method.
How often is really up to you. I assume that this is only for a few users from what you said in the question, so you don't need to worry about overloading the server. Once a minute sounds reasonable, but once a second would proabably be fine too if you feel that way inclined... Parsing JSON in .NET answers your final query.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I would like input on the design I currently have planned.
Basically, I have some number of external instrumentation, each of which should always be running, collecting specific data. My thought was to create a service for each, always running and polling the instruments, performing logging, etc. There could be one instrument, or there could be 40.
However, I need one application to consume all this data, run some math on it, and do the charting, display, emailing, etc. The kicker is that even if this application is not running, the services should constantly be consuming data. Also, these services should almost always be supposed to run on the same machines as the client application itself, but the ability to network them (like .NET Remoting used to do) could be an interesting feature.
My question is... is this the best design? If it is, how do I go about doing the communication between services and application? I've looked into WCF, but it seems to be geared towards request-response web services, not something that is continually streaming data to anything that might listen to it. Alternatively, should I have these services contact some other Web Service using WCF, that then compiles the data for use in a thin client viewer that polls the web service often?
Any links and resources would be greatly appreciated. .NET namespaces for me to research are also appreciated. If I wasn't clear about something let me know.
Just a thought....but have you considered perhaps adding a backend database? All services could collate data and persist it then your application that needs to process the information can just query the database rather than setting up loads of IPC between the services.
WCF can handle streaming. It can also use MSMQ as a transport, which will ensure that no messages are lost, even if your instruments begin producing large quantities of data.