I have got a simple TCPlistener that listens for connections and once a connection has been established, a method tries to send data and the server side tries to read it.
client side:
using (NetworkStream stream = new NetworkStream(_client.Client, false))
{
Serializer.Serialize(stream, MyPersonObject);
}
Server side:
using (NetworkStream stream = new NetworkStream(_client.Client, false))
{
var myObject = Serializer.DeSerialize<Person>(stream);
}
However, I've noticed that once it hits the DeSerialize method, it hangs and waits indefinitely.
Note that this does NOT happen with BinaryFormatter using the exact same steps. I am not sure what's wrong.
A protobuf stream is not "closed" - it reads until the end of the stream by default, which means it will read until the inbound TCP socket is mark as complete.
If you intend to send multiple messages, try using the "WithLengthPrefix" versions of serialize and deserialize; that adds message framing for you, allowing it to know where each payload ends.
Related
I serve various TCP clients asynchronously via their respective TCP sockets. Currently, I have 3 tasks running simultaneously:
Await data from the NetworkStream using await StreamReader.ReadAsync()
Write data into the NetworkStream using await StreamWriter.WriteAsync()
Send watchdog messages periodically
Now, when I call something like this:
var stream = new NetworkStream(_socket);
// reading task
using (var reader = new StreamReader(stream)) {
// ...read...
}
The underlying NetworkStream gets eventually destroyed after reading has been done because StreamReader closes it on Dispose().
The easiest way would be not closing the StreamReader, but AFAIK this is a very bad idea. So, how can I handle asynchronous reading and writing while keeping the socket connection open?
From .NET 4.5 onwards, if you look through the constructor overloads for StreamReader and StreamWriter, there is one (and currently only one) constructor that takes a bool leaveOpen parameter. Use this overload and pass true - then it won't feel ownership of the underlying stream.
If this isn't available on your framework version, you'll have to create a NonClosingStream : Stream that decorates a stream using pass-thru implementations for everything except Close() and Dispose(), which should be no-ops (well, they could assign null to the field that represents the wrapped stream, but nothing more).
Since the StreamReader will always dispose the underling stream on its own disposal (that's why actually it is IDisposable), you do indeed have to not close it until you have no need in the network stream anymore.
So, this is very ok for the situation:
var stream = new NetworkStream(_socket);
var reader = new StreamReader(stream);
And when you are finish, you would close both of them, right?
reader.Dispose();
stream.Dispose();
I am new to both C# and to client-server programming. Right now, for class, I'm attempting to create an FTP client without using any pre-established FTP libraries. I feel like I have the project down for the most part, however I'm running into a problem when I make more than one call that requires use of the data port (list, retr, etc.) Here is a sample of the code that is breaking:
writer.WriteLine(portcmd);
writer.Flush();
GetServerMessage(stream);
writer.WriteLine("list ");
writer.Flush();
tmpserver = new TcpListener(IPAddress.Any, 3128);
tmpserver.Start();
tmpclient = tmpserver.AcceptTcpClient();
Console.WriteLine("gothere");
if (!tmpclient.Connected)
{
tmpserver.Start();
}
StreamReader tmpreader = new StreamReader(tmpclient.GetStream());
GetServerMessage(stream);
while (tmpreader.Peek() != -1)
{
Console.WriteLine(tmpreader.ReadLine());
}
tmpclient.Close();
tmpserver.Stop();
GetServerMessage(stream);
Getservermessage is a method that takes a network stream and prints out everything available within a .5 second timeout, stream is the NetworkStream for the current connection to the FTP server, and writer is that same network stream wrapped in a StreamReader for ease of writing ASCII characters to the server. In case you are wondering why I use a stream reader to read from the data connection, it is because the server closes the connection after it transmits the data so I could easily get an eof notification. My GetServerMessage method was for some reason breaking when I used the closed network stream.
This code is sending the port command to the FTP server to inform it that I will be requiring a data connection (first 2 lines) Then sending the list command, establishing the data connection to the server, getting the desired information, and then terminating the data connection (the rest of the code).
This code will execute without flaw the first time I run it but if I try it again, it hangs on the 'tmpclient = tmpserver.AcceptTcpClient();' line. It never reaches the "gothere" print statement. I believe this is because I am receiving the client from the same machine on the same port but I'm not sure. I tried adding a Boolean value to make sure the AcceptTcpClient() only ran once but then I got a runtime error and visual studio informed me that I may have 'released resources before I was done with them' I predicted this would be a problem but how can I tell if the server reestablishes the connection after it has closed it once?
At the end of the given code I stop tmpserver and close tmpclient. I originally did this because I knew the FTP server would close the connection when it was finished transmitting and thought it was the proper thing to do. I find if I comment out these lines, the code will execute more than once but the streams appear to be empty... I'm not sure if this information is helpful but I figured I'd mention it.
I apologize if I am unclear at all but my lack of knowledge with the subject makes it difficult to articulate my problem. If there is any confusion over what the problem is I'd be happy to attempt to clear it up.
To be able to accept another client you should execute tmpclient = tmpserver.AcceptTcpClient(); and waiting for the first client to finish its works(before accepting second client) may not be a good idea
Here is a sample server code that waits for the connections and echoes strings sent from each client. You can test it with telnet localhost 3128
Thread t = new Thread(Server);
t.IsBackground = true;
t.Start();
-
void Server()
{
TcpListener listener = new TcpListener(IPAddress.Any, 3128);
listener.Start();
while (true)
{
var client = listener.AcceptTcpClient();
new Thread(() =>
{
using (client)
{
var reader = new StreamReader(client.GetStream());
var writer = new StreamWriter(client.GetStream());
while (true)
{
string line = reader.ReadLine();
if (line == "QUIT") break;
writer.WriteLine("From Thread[" + Thread.CurrentThread.ManagedThreadId + "] > " + line);
writer.Flush();
}
}
}).Start();
}
}
OK, it's like this. To do a server in a simple manner, you need to thread off the code that handles the client socket. When the accept returns, create and start a thread, passing it the 'tmpclient' and then loop around to the accept call again so that any new client can connnct up. In the newly-spawned server<> client thread, read and write to the passed socket in a loop to communicate with the client.
Once you close your tcp client stream, you can no longer read from the stream you pulled from it.
var stream = tcpClient.GetStream();
...
tcpclient.Close();
...
stream.Read .. fail
The client would have to request another connection,
OR
You should keep your tcp client sockets open.
More complex servers will keep some metadata (state) cached about the client so when sockets unexpectedly close - and the client quickly tries to reconnect, the server can continue processing the smoothly.
I have been sending binary data between applications lots of times over TCP sockets but never before using strings. Bumbed into an issue intending to do so. Here is what I got:
TcpClient tcpClient = new TcpClient("localhost", port);
//Connects fine
NetworkStream ns = tcpClient.GetStream();
StreamWriter sw = new StreamWriter(ns);
//The code moves on but nothing seems to be sent unless I do
//a sw.Close() after this line. That would however close the
//ns and prevent me from reading the response further down
sw.Write("hello");
//I am using a stream reader with ReadToEnd() on the tcpListener
//which never receives the string from this piece of code
//Since the above never actually send I get stuck here
string response = new StreamReader(ns).ReadToEnd();
sw.Close();
tcpClient.Close();
How do I send the string without closing the network stream? ns.Flush() is what I would be looking for really.
You have an sw.Flush() , that ought to work. A WriteLine() might have done it too.
But when the other side does a ReadLine() then you have to make sure you end with newline. Try WriteLine() instead of Write().
And be careful about closing a StreamReader/Writer, they also close their underlying streams.
There's a StreamWriter.Flush(). When you get done with sending you message, just do sw.Flush(). However, since buffer sizes are fairly large (upto a couple KB), the correct way is to only Flush() just before you wait for a response. That way several calls to .Write() can be bundled into a single packet and sent down the wire at the same time.
You just need to set the AutoFlush property on the StreamWriter to true.
i am trying to disconnect a client from a server but the server still sees it as being connected. I cant find a solution to this and Shutdown, Disconnect and Close all dont work.
Some code for my disconnect from the client and checking on the server:
Client:
private void btnDisconnect_Click(object sender, EventArgs e)
{
connTemp.Client.Shutdown(SocketShutdown.Both);
connTemp.Client.Disconnect(false);
connTemp.GetStream().Close();
connTemp.Close();
}
Server:
while (client != null && client.Connected)
{
NetworkStream stream = client.GetStream();
data = null;
try
{
if (stream.DataAvailable)
{
data = ReadStringFromClient(client, stream);
WriteToConsole("Received Command: " + data);
}
} // So on and so on...
There are more writes and reads further down in the code.
Hope you all can help.
UPDATE: I even tried passing the TCP client by ref, assuming there was a scope issue and client.Connected remains true even after a read. What is going wrong?
Second Update!!:
Here is the solution. Do a peek and based on that, determine if you are connected or not.
if (client.Client.Poll(0, SelectMode.SelectRead))
{
byte[] checkConn = new byte[1];
if (client.Client.Receive(checkConn, SocketFlags.Peek) == 0)
{
throw new IOException();
}
}
Here is the solution!!
if (client.Client.Poll(0, SelectMode.SelectRead))
{
byte[] checkConn = new byte[1];
if (client.Client.Receive(checkConn, SocketFlags.Peek) == 0)
{
throw new IOException();
}
}
From the MSDN Documentation:
The Connected property gets the
connection state of the Client socket
as of the last I/O operation.
When it
returns false, the Client socket was
either never connected, or is no
longer connected. Because the
Connected property only reflects the
state of the connection as of the most
recent operation, you should attempt
to send or receive a message to
determine the current state. After the
message send fails, this property no
longer returns true. Note that this
behavior is by design. You cannot
reliably test the state of the
connection because, in the time
between the test and a send/receive,
the connection could have been lost.
Your code should assume the socket is
connected, and gracefully handle
failed transmissions.
I am not sure about the NetworkStream class but I would think that it would behave similar to the Socket class as it is primarily a wrapper class. In general the server would be unaware that the client disconnected from the socket unless it performs an I/O operation on the socket (a read or a write). However, when you call BeginRead on the socket the callback is not called until there is data to be read from the socket, so calling EndRead and getting a bytes read return result of 0 (zero) means the socket was disconnected. If you use Read and get a zero bytes read result I suspect that you can check the Connected property on the underlying Socket class and it will be false if the client disconnected since an I/O operation was performed on the socket.
It's a general TCP problem, see:
How do I check if a SSLSocket connection is sane on Java?
Java socket not throwing exceptions on a dead socket?
The workaround for this tend to rely on sending the amount of data to expect as part of the protocol. That's what HTTP 1.1 does using the Content-Length header (for a entire entity) or with chunked transfer encoding (with various chunk sizes).
Another way is to send "NOOP" or similar commands (essentially messages that do nothing but make sure the communication is still open) as part of your protocol regularly.
(You can also add to your protocol a command that the client can send to the server to close the connection cleanly, but not getting it won't mean the client hasn't disconnected.)
I am trying to implement a tcp client listening function. This means that after connection established with server, this tcp client just sit there and waiting for new data to arrive.
Here is my code but when it runs, it complain about not been able to read anything from the
network stream. But the server hasn't started sending data yet. I guess the complains is because
of the timeout in tcp client.
Is this the right way to do it?
public void listen(dataHandler processDataFuc)
{
NetworkStream stream;
Byte[] data_buffer = new Byte[MAX_PACKET_SIZE];
if(!this.Connected)
{
this.Connect();
}
while (!this.terminate_listening)
{
stream = main_client.GetStream();
while (stream.Read(data_buffer, 0, data_buffer.Length) > 0)
{
processDataFuc(data_buffer);
}
}
}
Thanks
The short answer is yes, it'll do what you want, but it's not ideal. I'd first suggest moving stream = main_client.GetStream(); out of the while loop, as you're just getting the same stream over and over. Also, using NetworkStream.Read isn't the best way to perform a continuous read if you're expecting intermittent data over a long period of time, as it's holding up a thread just for that one task; better to use BeginRead and pass in a callback, which will return immediately but later alert you when data is available (via the callback).
Checkout the methods EstablishConnection() and IncomingDataSyncWorker() (synchronous) or IncomingPacketHandler() (asynchronous) for examples of what you want to do. All these methods are part of networkComms.net an opensource network communication library.
What version of .Net are you using?
If you are using .Net 4.0 or 4.5, then you can use ReadAsync() instead of Read().
Consider this:
public async void listen(dataHandler processDataFuc)
{
NetworkStream stream;
Byte[] data_buffer = new Byte[MAX_PACKET_SIZE];
if(!this.Connected)
this.Connect();
stream = main_client.GetStream();
while (!this.terminate_listening)
{
await stream.ReadAsync(data_buffer, 0, data_buffer.Length)
processDataFuc(data_buffer);
}
}
In such way, ReadAsync() will waits in a separate Thread until server sends some Data. Then the rest of your code will execute.