I am currently writing a system logging program which sends different logs via ftp.
The Problem I am facing is that my program should constantly check if the connection is being used before and during it's upload in order to stop sending packets if a different program wants to use the connection.
I actually found this link helping me measure the speed of the connection, but I think I can only use the latter in order to discover if the something is already being streamed.
After reading the library entry on System.Net.NetworkInformation, checking various Network Statistics and states wasn't a problem either. As stated beforehand my only problem is checking if some other program wants to send something.
As you can probably tell from the question, I am very new to this topic and a fairly junior programmer. I have been reading up on the System.Net.NetworkInformation Namespace library and facilitating it's various classes, methods and delegates. I have the feeling that I am on the right track, but just not getting there. Anyone got a push in the right direction?
Thank you.
I ended up using the System.Net.NetworkInformation library and it's methods.
The methods GetIsNetworkAvailable(), NetworkChange.NetworkAvailabilityChanged Eventhandler and the TcpStatistics helped me gather information on the connection. MSDN and the reference is a great guide in using the foregone mentionend methods and I basically used the examples with slight modifications to suit my needs.
msdn NetworkInformation:
http://msdn.microsoft.com/de-de/library/system.net.networkinformation.aspx
The GetIsNetworkAvailable is pretty straight forward returns boolean value on connection being up or down.
Networkchange.NetworkAvailabilityChanged triggers an event on connection loss or reconnection. See the msdn link above for an excellent and very usuable example on it's usage.
And the TcpStatistics return information on how many connections have been accepted, initiated, errors received, failed connections, connection resets and more. These were the five I used so far to evaluate the connection.
I realized that you do not really need any more to monitor the connection efficiently.
Maybe the method NetworkInterface.GetAllNetworkInterfaces() can help finding out which Networkadapter is sending the data and should be monitored.
I now understand the comments of Peter Ritchie to my question. FTP transmission runs extremely well and the protocol handles the transmission of the files flawlessly and no problems have arisen up until now in streaming the log files. In 4 weeks of testing I have received the logging data constantly.
Related
I'm an amateur programmer working on a pet project of mine and I would like some pointers on how to make a C# server application. Here's the general idea:
A client connects to the server application, which in turn fetches the necessary information from a mysql database and sends it back to the client to be displayed and wait for the next action.
I got the idea of making something like this after seeing a somewhat old IBM AS400 mainframe running a warehouse management system, and I though: "Hey, I could try developing a small version of this with a nice UI that doesn't look like it stepped out of a time machine!"
I searched around and used the tcplistener class to communicate between the server and client and managed to send some calls and responses using one thread per client. However I've read that this is not scalable for a large number of clients...
Am I looking at this problem the wrong way and I should try something else? Any input will be appreciated
You don't need to deal with TCP directly for this - WCF (Windows Communication Foundation) was written to abstract all the low level stuff from you.
Check this link out for a good example of how to create a client/server application, it has an entry level explanation, some code and a downloadable project...
http://www.codeproject.com/Articles/16765/WCF-Windows-Communication-Foundation-Example
You can find plenty of information about WCF elsewhere on the internet and here on SO.
It is a very large topic, but the situation you have described is pretty simple - so I doubt you will have problems following the example.
I'm Currenty writing a server architecture and came across this as well: faily easy to solve.
You're right, using 1 thread per client is not effiecient and is a huge waste or resources! The way around that is Thread Pooling. There are loads of different ways to do this but the way I chose to implement it on my server was to add every connection to a queue and then have x number of threads (which you can easily increase or decrease to handle demand) simply dequeue a connection, process it, then enqueue it again.
Of course using WCF will make life easier for you and will speed things up drastically but where's the challange in that!
Now, I'm interested to know - if I have a program of mine connection to a Server through TCP and the server sends a message to my program, but I am sending UDP packets at the same time, will the TCP packet get to me? Everything is in one class!
Thanks for your help!
Your question is actually on the border of several issues that all network application programmers must know and consider.
First of all: all data received from the network is stored in operating system's internal buffer, where it awaits to be read. The buffer is not infinite, so if you wait long enough, some data may be dropped. Usually the chunks of data that are written there are single packets, but not always. You can never make any assumptions of how much data will be available for reading in TCP/IP communication. In UDP, on the other hand, you must always read a single packet, otherwise the data will be lost. You can use recvfrom to read UDP packets and I suggest using it.
Secondly: using blocking and non-blocking approach is one of the most important decisions for your network app. There is a lot of information about it in the Internet: C- Unix Sockets - Non-blocking read , what is the definition of blocking read vs non- blocking read? or a non-blocking tutorial.
As for threads: threads are never required to write a multiple connection handler application. Sometimes they will simplify your code, sometimes they will make it run faster. There are some well-known programming patterns for using threads, like handling each separate connection in a separate thread. More often than not, especially for an inexperienced programmer, using threads will only be a source of strange errors and headaches.
I hope that my post answers your question and addresses the discussion I've been having below another answer.
Depends on what you mean by "at the same time". Usually the answer is "yes", you can have multiple TCP/IP connections and multiple UDP sockets all transmitting and receiving at the same time.
Unless you're really worried about latency - where a few microseconds can cause you trouble. If that's the case, one connection may interfere with the other.
Short answer - Yes.
You can have many connections at once, all sending and receiving; assuming that you've got multiple sockets.
You don't mention the number of clients that your server will have to deal with, or what you are doing with the data being sent/received.
Dependent on your implementation, multiple threads may also be required (As Dariusz Wawer points out, this is not essential, but I mention them because a scalable solution that can handle larger numbers of clients will likely use threads).
Check out this post on TCP and UDP Ports for some further info:
TCP and UDP Ports Explained
A good sample C# tutorial can be found here: C# Tutorial - Simple Threaded TCP Server
I am attempting to send player information from my Game to my network client to then be sent off to the server.
Currently the ClientNetwork -> ClientGame relationship is held with XML files. They read/write back and forth at very high speeds. If you use just one XML file for this trade, one will "hog" the file at times, making a kind of lag when one cannot read because the other is viciously writing and rewriting.
To fix this I have 2 of each of my XML files. If it cannot read one, it will read the other. In theory they should be using both of them, since it'd be a tradeoff from one to another. Not working up to par.
But my main problem is just the usage in general of XML is very sloppy, dozens of try-catch statements to make sure they're all happy (and my personal favorite, try catches within try catches -- WE HAVE TO GO DEEPER)
I am just curious of if there is a better way to be doing this. I need a static point of variables that can be accessed by both client side programs. I'm afraid someone is going to say databases...
I'd like to state for anyone who is looking into this as well and stumbled across this page that Shared Memory is awesome. Though I have to convert all strings to characters and then to bytes and read them one by one, in the whole it's ALOT better than dealing with things that cannot read/write the same file at the same time. If you wish to further understand it rather than just use it, go to this link, it explains a lot of the messaging varieties and how to use them.
Yes there is!
The term you are looking for is interprocess communication - communication between two processes on the same machine.
There are various methods which allow two processes on the same machine to communicate with each other, including:
Named pipes
Shared memory
Sockets
HTTP
Fortunately C# applications can simply use the WCF framework to perform IPC (interprocess communication) using one of the above, and let the WCF framework take care of the difficult bits! Here are a couple of guides to get you started (there are many more):
WCF Tutorial - Basic Interprocess Communication
Many to One Local IPC using WCF and NetNamedPipeBinding
Also, one of the neat things about WCF is that you can also use it to communicate between different machines simply by changing the "Transport" (i.e. the communication method) to one which works over a network, (e.g. HTTP).
If you are targetting .Net 2.0 then you should look into either .Net remoting or web services instead.
A simple TCP stream jumps out at me. Have the network client open a listening TCP socket, and have the game connect to the network client. You could continue to send the same XML data you're already writing, if you like.
I agree with the tcp/ip socket answer proposed by David. I would simply submit the data to a socket on the local pc and have the other application listen to the socket. You can transmit data easily and quickly using this method and it will work no matter what version of the .net framework you are targeting.
I've been looking for a decent network library for C#.
It is going to be used with XNA 3.1, and .NET Framework 3.5.
The multi-player style is going to be Server and Client.
Currently I have been looking into Lidgren Library Network, but it seems outdated.
Anyone got some good suggestions for a good network library. It should be able to handle easily 30+ client connections at a time.
Although there is nothing stopping you from writing all of the low level networking code yourself, using a library is definitely a great way to save loads of time and stress, time which you can then better spend improving your own application.
A library not already mentioned here is networkComms.net. It has a plethora of sophisticated features (such as serialisation, compression and encryption) but given you mention number of connections specifically it is capable of handling 1000+ connections with transfer rates of 1Gbps+. There is a simple article on how to create a quick client server application but in brief you could send and receive as follows.
To send:
//This is the simplest way to send with more advanced options also available
//Parameters are message type, IP address, port and the object to send
NetworkComms.SendObject("Message", "127.0.0.1", 10000, "Networking in one line!")
To receive:
//We need to define what happens when packets are received.
//To do this we add an incoming packet handler for
//a 'Message' packet type.
//
//This handler will automatically convert the incoming raw bytes into a string
//(this is what the <string> bit does) and then write that string to the
//local console window.
NetworkComms.AppendGlobalIncomingPacketHandler<string>("Message", (packetHeader, connection, incomingString) => { Console.WriteLine("\n ... Incoming message from " + connection.ToString() + " saying '" + incomingString + "'."); });
//Start listening for incoming 'TCP' connections. The true
//parameter means try to use the default port and if that
//fails just choose a random port.
//See also UDPConnection.StartListening()
TCPConnection.StartListening(true);
Disclaimer: I'm one of the developers for this library.
Your link is indeed outdated; but if you read the page it will direct you to the newer version: http://code.google.com/p/lidgren-network-gen3/
You seem to be looking in the wrong place. You don't seem to have looked in the .NET Framework itself.
What about using WCF? What about using TcpListener?
What do you need that these do not provide?
WCF is one possibility, though it may be a bit heavyweight for this scenario. .NET Sockets, OTOH, are often too low-level; they're not an easy "component" to just plug in (both networking and multithreading must be learned well before the Socket class can be used correctly).
I wrote a library, Nito.Async.Sockets, which is part of Nito.Async. It removes multithreading considerations from socket programming, and also includes a higher-level abstraction that handles message framing and keepalives.
How is lidgren outdated? It is still the only major player in the .NET space for gaming networking.
Have you tried the inbuilt .Net libraries found in System.Net? It is very unlikely that you need to use an external library at all. Here's an example of simple threaded TCP server and you may want to look at UDP as well. There are loads of tutorials if you just google around a bit.
Try looking at the System.Net.Sockets MSDN page for more information.
At this point I would like to throw my library into this thread. NuGet available as well.
I suppose similar questions were already asked, but I was unable to find any. Please feel free to point me to an existing solutions.
I'll explain my scenario. I'd like to create a server application. There are many clients (currently only a few dozens, but it should scale up to 1000+) that connect to the server (which is running on a single machine).
Each client periodically sends a small amount of data to the server to process (processing is quick). The server can also send small amounts of data to each client on a regular basis. The response time should be low (<100 ms), but realtime or anything like that is not required.
My first idea was back from when I was still programming in VB6: Create a server socket to listen to incoming requests, then create a client socket for each possible client (singlethreaded). I doubt this scales well. It is also difficult to implement the communication.
So I figured I'd create a listener thread to accept new client connections and a different thread to actually read the incoming data by the clients. Since there are going to be many clients, I don't want to create a thread for each client. Instead, I'd prefer to use a single thread to read all incoming data in a loop, then either processing these data directly or creating work items for a different thread to process. I guess this approach would scale well enough. Any comments on this idea are most welcome.
The remaining problem I'm worried about is easy of communication. The above solution seems to require a manual protocol, possibly sending ASCII commands via TCP. While this would work, I think there should be a better way nowadays.
Some interface/proxyish way seems reasonable. I worked a bit with Java RMI before. From my point of understanding, .NET Remoting serves a similar purpose. Is Remoting a feasible solution to the scenario I described (many clients)? Is there an even better way I don't know of yet?
Edit:
This is not in LAN, but internet, if that matters.
If possible, it should also run under Linux.
As AresnMkrt pointed out, you should try WCF.
Just take it as is (with netTcpBinding, but don't forget to switch security off) and create a Tracer Bullet - measure if performance meets your requirements.
If not, you can try to tune WCF - WCF is very extensible, and you can modify message serialization to send ASCII messages as you want.
Are you sure you need a binary protocol? Rather, are you sure you need to invent a whole new protocol where plain RESTful service with JSON/XML will suffice? WCF can help you in this regard a lot.