My application uploads files to server of my client, but he want special "pause upload" function. I cant simply close connection, not even kill process - he need to lost connection otherwise his server application delete unfinished file - so i have to simulate in code "cable unplug" - do you have any suggestion?
thanks for your help and sorry for my english :)
jirka
You can use Mockito to create a Socket mock for your unit tests, as suggested on this question: Testing Java Sockets
If you wrote both the client and the server, maybe the better option is to send some OOB data to tell the server that you are pausing (or a message to tell the server to not delete the file on next socket close). It is usually better to be explicit instead of relying on side effects of certain actions - in your case, closing a socket without explicit connection termination.
Related
I have an app which uses an instance of the Socket class to communicate with a server.
I use the streams returned by socket.getInputStream() and socket.getOutputStream() to read and write data.
When my Android app is always "active" (not minimized), there is no problem with the communication. It does not matter how long the connection lasts.
When I "pause" the application and re-open it quickly, everything still works fine.
However, when I pause the application for about 5 minutes and re-open it, the InputStream shows strange behavior: it stops reading anything. I get timeout errors instead of the data sent by the server.
The connection is still alive, the server is able to write and read. isInputShutdown() on the client-side returns false.
Using a network analysis tool, I can also see that the data sent by the server IN FACT reaches the client but it somehow does not get recognized by the InputStream ...
However, writing data from the client to the server using the OutputStream works fine.
Maybe it's worth mentioning that the socket object and the streams are declared as static to be accessible for all the activities of the app. But as I don't have any problems with the OutputStream, I cannot imagine that this could be the reason.
The only workaround I have at this point is to close the whole socket and connect a new one to the server. But this is causing unnecessary network traffic because I have to handshake again. It would be better not to do it this way.
If anyone has had similar experience and found a solution, I would be really happy if you could share it with me.
You should create a service that will be run in background and implement socket connection with a server.
As Kevin Krumwiede pointed out by referring to this post: Strange behavior of socket outputstream android, when sending data every X minutes (e.g. 3 or 4), everything still works as it should even after 30 minutes of being 'paused'.
I had the hope that Socket.setKeepAlive(true) would be enough to keep the connection alive so I dont have to cause too much unnecessary network traffic but in my particular case, this does not help.
Sending 1 byte of 'garbage' every X minutes 'solves' the problem.
What I have is a multi threaded socket server listening for clients. New thread is created and started for opened connections. Clients can ask a server to execute some commands via Runtime .exec() method. Any new command received is handled by new thread (with PrintWriter passed as a parameter) and all the output (std/err) is send over the socket with PrintWriter.
The problem is that when the command takes longer (i.e. daemon) and the client disconnects for any reason I can't get the output anymore. I need to find a way of getting the output from that command execution thread on another connection (new client session which will be on another thread).
I could try to send all the output from commands to System.out and try to send it (System.out) over socket with PrintWriter (I don't know how to do this). And if I'm sucessfull maybe there is a way of sending all the such an output to every connected clients.
But then, I'm saving all the output to the database and in case of multiple clients connected I would end up having multiple inputs in my database.
Please give me some ideas as how I could go about with this issue. Thanks
You probably want to make your calls asynchronous. Executing tasks of unknown duration should never be made synchronously.
I would consider using a "reactor"-type server (i.e.: one thread per client = quick death) and using some type of message passing mechanism for long running transactions. There are a lot of middlewares that do this kind of work, it really depends on what platform you're on.
By the way, using a socket connection to execute command on a remote machine is a security flaw, but you probably already know that!
So, did you consider using a session ID for each connection? This ID will be associated with the output of each execution. So the same output could be retrieved on a subsequent call from the same user. Temporarily, the output could be stored at a repository (e.g. DB, memory, file).
Please correct me if I am not getting your question properly.
I'm new to Java and RMI, but I'm trying to write my app in such a way that there are many clients connecting to a single server. So far, so good....
But when I close the server (simulating a crash or communication issue) my clients remain unaware until I make my next call to the server. It is a requirement that my clients continue to work without the server in an 'offline mode' and the sooner I know that I'm offline the better the user-experience will be.
Is there an active connection that remains open that the client can detect a problem with or something similar - or will I simply have to wait until the next call fails? I figured I could have a 'health-check' ping the server but it seemed like it might not be the best approach.
Thanks for any help
actually i'm just trying to learn more about RMI and CORBA but i'm not that far as you are. all i know is that those systems are also built to be less expensive, and as far as i know an active conneciton is an expensive thing.
i would suggest you use a multicast address to which your server sends somehow "i'm still here" but without using TCP connections, UDP should be enough for that purpose and more efficient.
I looked into this a bit when I was writing an RMI app (uni assignment) but I didn't come across any inbuilt functionality for testing whether a remote system is alive. I would just use a UDP heartbeat mechanism for this.
(Untested). Having a separate RMI call repeatedly into the server, which just does a "wait X seconds" and then return, should be told that the execution has failed when the server is brought down.
I am having a few issues with sockets within my Java SIP client. When I bind to an address and port, if something goes wrong I have to attempt to reconnect, usually after I've stopped and restarted the process. Problem with that is then the port is bound and I am forced to increment the local port.
How can I remove the binding to the port I am targeting before binding to it?
If that isnt possible, then how can I trap the process just before it ends so that I can locate the socket binding and close it manually?
#Jason - Jason, but in this case I am writing the Client and have no access to the server, the port I am referring to is on the client and is local. Is there a way to flush the port binding before attempting to connect? If not is there a way to trap the process interrupt, as in perl there is a way to trap a 'die' signal and do some post processing, does Java have this? If so I could call close() on the socket connection
In my experience 9 times out of 10, the answer to this class of problem is, "Look up SO_LINGER".
If you pull the plug (literally) on a client, the server optimistically hopes it will come back to collect the data you already sent on that socket. So it holds onto that data, and the port, until the buffers clear.
Usually on the server you want to kill these buffers with extreme prejudice, due to the sort of DOS attack (intentional or accidental) you just discovered.
Don't fiddle with SO_LINGER, it just adds insecurity. The real question is why are you binding to a local port at all?
Ok - I found a way to trap Java signals by reading this tutorial online - http://www.ibm.com/developerworks/java/library/i-signalhandling/
This way one can trap the die signal and close the connection.
I am designing a Client Server Chat application in Java which uses TCP connection between them. I am not able to figure out how to detect at server side when a client forcefully closes down. I need this as i am maintaining a list of online clients and i need to remove user from the list when he forcefully closes the connection.
Any help will be highly appreciated.
Thanks
Tara Singh
One way to receive timely notification of a disconnect is to attempt to send a small piece of information at regular intervals. Then, the latest that you'll know of a client disconnect is at most your interval. People call this a heartbeat.
Assuming that your server is using a java.net.Socket, you can query the socket from time to time, it provides methods isClosed() and isConnected().
It depends on how you're handling your socket I/O
For example, if you're using a selector (java.nio) to do non-blocking I/O on a set of sockets you're going to find out about any disconnects the next time you call select().
Maybe if you updated your question with how you're handling the sockets?