I'm making an OPC client on winforms, client that connecting with server and reading data from it with OPC protocol. So, I successfull connecting to server, but when my program crashing or I'm closing it manually from task manager, connection with server is still exist (and that's not good).
Can I somehow check my program for correct ending ? And if my program ends incorrect then disconnect from server.
I tried to use myProcess.HasExited, but it's not working.
I can only guess you can use Socket for server connection. If so, then this is a good practice to close it once you've done with server call. You need to call sequence of Shutdown(), Close(), Dispose().
See this MSDN article: https://msdn.microsoft.com/en-us/library/wahsac9k(v=vs.110).aspx
Related
I have a tcp server that writes in winforms and a client in android. I connect devices to a wirless network then I disconnect server from this network. However client continue to listen server for a while then it closes its socket. How can I tell client to close socket when server is disconnected from network?
The reason it happens (if I understand the problem correctly) is that there is not inherent way to know that a connection has been closed, unless you try to send a package. So in your client, if you try to send an empty package over the connection, it will immediately report if the connection has been closed.
This is the reason that Heartbeats exist, and you can configure your socket to use them, or you can have your client periodically (or when needed) attempting to send an empty package and report the status of the connection.
There is an excellent article on CodeProject about this, see here.
I have a small client/server application. I was using a hand-coded TCP connection to allow the client to control the server, but now I've converted it to WCF. This saved me a whole bunch of code, but it also gave me a whole new set of problems to fix...
The latest problem is that after a while, the server disconnects the client. I do not want this to ever happen, under any circumstances. Currently the client gets about a quarter of the way through its run, and then explodes with fire because the server has dropped the connection. I need to stop this happening.
I was able to write a trivial WCF client/server pair that replicates the problem. It seems that if the client calls a method, waits 15 minutes, and then calls a second method, the second call throws an exception babbling something about the socket having been closed. If I reduce the delay, everything works fine.
I read in another answer somewhere that setting ReceiveTimeout should fix this. However, when I tried it, this only fixes the problem under .NET; when running under Mono, it still breaks. Since Mono is the actual target platform, this isn't very helpful.
(Think about SSH - you would not want an SSH server to disconnect you just because you didn't type anything for a while. Perhaps you issued a long-running shell command or something... Just because the server hasn't received any data from you doesn't mean nothing is happening! It certainly doesn't mean your connection should get dropped...)
All code is C#. The server is a self-hosting console app. The client is also a console app. All configuration is in code. Binding is NetTcpBinding with default settings.
What can I do to allow the client to run to completion successfully?
I have a few ideas, but none of them are pretty:
Manually send heartbeat messages. (Yuck!)
Detect disconnection and automatically reconnect? (Again, yuck.)
Turn on "reliable mode". (I'm guessing that since the server deliberately ends the session, this won't help.)
Create one connection per method call. (That's going to be quite a lot of code...)
Stop using WCF?
In the end I "fixed" this by having the client make a new connection for every single command. This works acceptably because the client doesn't send commands all that often. It's annoying having to write the connect/disconnect code a dozen times though...
I'm working on a C# WebSocket server (currently supported by https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-17).
The server is working with the Socket object of the .NET for the server to listen and for each client to send and receive messages.
I built a web client that connect to the server, It can connect successfully and i can send messages between clients.
Everything is working great!
Now, if i'm connecting to the server and leave the client for a while without sending messages, the server throwing an exception that says:
Int32 Send(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags):An
existing connection was forcibly closed by the remote host.
The exception, as you can see is from the Send method of the client socket in the server, this is looks very wired because i didn't sent any data from the client and no one sending data to this client back so how can it be that the Send method can throw an exception and why this exception is thrown?
It's called a timeout!
WebSockets are just a wrapper around TCP/IP raw sockets (Socket class in .NET) - which timeout if nothing is sent, and nothing is keeping the connection alive.
AFAIK currently the WebSocket API isn't very well defined as far as how to keep the connection alive. I was experiencing the same and had to just switch over to using a ping (empty message) to keep the connection alive (I'm using the Microsoft sockets implementation).
If you're reinventing the wheel for a non final spec, just remember that you'll have to keep reinventing it every time the spec changes. I specifically chose to use the Microsoft sockets preview so that when it's released I'm pretty much not going to have to change any code. I don't run in IIS - I run as a console app and it's working mostly great so far but I have very very few users.
Note: The problem i was having that led me to find this question was if I send 10 messages without receiving a reply then the connection is closed. I'm still looking into why this is - whether its a bug / feature of WebSockets or a feature of the Socket class. it's possible I'm hitting a 65kb limit but my messages are small and I don't think that's why. Just be aware of this when testing whatever you're working on becasue it gives the same error you got.
I assume that you have exclude the usage of different protocols between the servers and the clients (silly assumption, but you never know).
If your code reaches the Send method without a prior Receive from the client, then it's obvious that something is wrong with the server code. Use trace and/or log to get more information even for abc's like entering wait to receive, receiving, received, exiting receiving etc.
I have written a sample client and server. The server keeps on listening while client connects, sends requests and then disconnects. I have a scenerio when the client connects to the server and before sending requests the server is shutdown forcefully or by any means. My question is how can I handle this? Can I keep the server from disconnecting unless it notifies its connected clients? Can I write such a method? How?
EDIT: by server and client i mean server and client applications I have written my self
Thanks
Please clarify your situation. The
server
means your server application or the physical server itself? If the server means the o/s itself, then nothing you can do except to perform a thorough software and hardware troubleshooting.
UPDATE:
Ok, if that is your application problem, then you can try to implement Try..Catch statement in your code and learn more for the exception being raised.
The point is that, you must prevent an exception in the first place rather than seeking solution when exception happens.
Since you are in control for both server and client application, you can use a comet approach to monitor the server application status, ie the server still running, or had shutdown.
For more information about the concept of comet approach, here is the link: http://www.codeproject.com/KB/aspnet/CometAsync.aspx
Unfortunate short answer: no. Lots of things can forcefully and unexpectedly shut down your server -- whether it be a network error, a system administrator, or a state-wide power failure.
The best you can do is ensure your client is able to handle sudden server disconnections.
I don't think there is anything you can do if the server is forcefully shut down. The best you can do is make sure the client checks to make sure the server is still up before it sends any commands. This will at least prevent the client from crashing.
If your client is always connected and able to receive commands from the server there is nothing stopping you from sending some kind of command to the client if the server is shut down in an orderly fashion.
I have a problem, I've developed a Client and Server wrapper for my personal use, but unfortunately due to insufficient knowledge in network programming, I have TIME_WAIT problems during connect on the client. My client tries to make multiple connections to the same host within short period of time now, I have found out that the main reason for that is because I'm trying to reuse the socket and it goes to TIME_WAIT state because I'm closing the connection without graceful shutdown. I would like to know the correct pattern to close connection using .NET sockets in case I'm using 'Async' APIs intensively i.e. functions like ConnectAsync, AcceptAsync, SendAsync, ReceiveAsync, DisconnectAsync (DisconnectAsync - reuses socket)
I have found out that it is impossible to prevent TIME_WAIT. Either server or client will have the problem any way, depending only on who initiates a closure of the connection first. If it's the client who closes the connection, there will be no TIME_WAIT on server. If it's the server who closes first, than there will be no TIME_WAIT on client. So the only option that is left to do is using SO_REUSEADDR, but in this case it is still impossible to use the reused address for contacting previously disconnected host
You can use SO_REUSEADDR on the socket to get around this. See Socket.SetSocketOption for details, it's the ReuseAddress option you need to set.
By the way you don't really mean reuse the socket do you? once you get an error, you have to close it and open a new one.