I've written a very simple server that accepts socket connections on a specific port
and communicates with clients over that socket.
Now I have a client lib which works perfectly fine in J2SE apps.
However, if I try to use that lib in a Servlet (the Servlet being the client) to communicate with the server it doesn't work.
Unfortunately there is no Exception or something that could help me.
Instead when using the lib simply nothing happens.
That is the call to the method within which the socket is opened just blocks indefinitely
while no connection is made to the server.
I reckon this could be a general problem.
Maybe things like that are not allowed from within a Servlet?
But even if not I would at least expect that some Exception to be thrown.
The Servlet Container is Tomcat by the way.
Has anyone got an idea as to why this doesn't work?
Ok here is there actual problem:
It seems to be a difference in behaviour between Windows and Linux.
I developed the server + lib under Linux while Tomcat runs on a Windows machine.
Among other things the server I told you about executes a command
via ProcessBuilder.
What actually blocked indefinitely was the Process#waitFor.
That is under Windows. Under Linux it works just fine and returns as soon as the process is finished.
Under Windows however Process#waitFor only returns when I read the Process's InputStream for some reason.
Sorry!
Related
I developed a java code to connect to a device and issue few POST commands. This runs well in eclipse. But when I build and run on command-line it always times out.
I am running eclipse in the same machine as command line .I am using java 8.
Network problems are best tackled by first keeping Java out of it. So as a first step, you can open up the console and try to do a telnet connection to the socket address you used in your program by entering
telnet targetserver.example.com 12345
If that times out as well, the source of your problem is not within Java.
You haven't provided much (e.g. source as requested) but my guess into the blue is that you're sitting behind a proxy that is configured in Eclipse. Eclipse passes that information to the started application so the connection works. Starting the application on the console lacks this information, so the network connection is attempted directly without going via the proxy.
I have been able to setup an rmi server and call it successfully with no problem in my debugging but when I am trying to use it in a 'real case' it hangs. My real case is a plugin for a 3rd party application where it makes calls to my server application. My client actually starts the server side by starting a new process which puts the object in the registry. My client then calls the stub and calls a method in it but it only gets so far then stops. If I then kill my client the server will continue. Its as if the client side is holding onto something that the server side needs but they are running in separate jvm's so I can't work out what it would be. I wouldnt have thought what the client was doing would have any affect?
As I said the debugging of this works, ie the client starts the server process and then calls to the server are ok. I'm not running it with a security policy as its only a demo for now but not sure if thats an issue? Its all running on one machine, not distributed in any way.
The client is in 1.6 whereas the server is 1.7, again, is that a problem?
I was wondering if anybody has had similar problems or can recommend another way to do what I'm trying to besides RMI. Any guidance appreciated.
I wrote a little java program that establishes a socket connection (port 23456) over TCP between a server (pong.java) and a client (ping.java). I start the server and then the client which sends ping and the server responds with pong. This happens 50 times.
This works all fine but now i want to shut this down using a SYN Flood DoS attack with hping3, but i can't get it to work. I can easily stop a file transfer running between the client and the server over SMB with the same DoS program. The server definitely gets the SYN packages- When i attack the same port the java socket connection uses it just shuts the attack down and the java program happily finishes the 50 loops. i can't figure out why. is there some protection in java or do sockets in java work different than a TCP exchange over SMB?
I do this for a network class and i just can't figure it out. I just attack myself between 3 VMs so no one will get harmed.
I can provide the source code or further information if needed.
Thanks a lot if anyone can help.
I don't know whether it fits or not, however I wrote a server-client app and more clients were trying to connect. As long as I used the Sun JRE, it worked. With the OpenJava, I was unable to get it work - only the first client connected, the others had to wait. I was unable to figure out why, and didn't really care - installed Sun (nowadays Oracle) JRE on the server and it run smooth. So if you use Linux and OpenJava, I suggest give it a try with Oracle's JRE.
Is it possible to write a Java applet that can be a server on the client machine within the client's local network?
To be more specific, what I am looking to do is tunnel non-web traffic over the web. The sender would send to the applet, which would then forward the received data back to the server.
Is this sort of thing possible? What are the restrictions that might get in the way?
Note: I know that the applet can connect back to the server, that isn't an issue. The issue is whether or not an applet can listen for a connection / data on a local, client-side port.
An unsigned applet can only connect the host they come from.
A signed applet can do any connection you want and can listen on tcp-ip ports.
Source : http://docs.oracle.com/javase/tutorial/deployment/applet/security.html
Server does not connect to anywhere. Server opens server socket and is listening.
In past as far as I remember the server socket was restricted in MSIE and was permitted in Netscape (do you remember such browser?) :)
I personally have not been writing applets for the last 10 years, so I have no idea what happens now with currently existing browsers, but it is very easy to check. Just write the shortest applet you can and put code new ServerSocket(1234).accept(); into its init() or start() method. If no exception was thrown you can write applet that functions as a server. Otherwise you cannot.
Just try it with all available browsers. 20 minutes work and you are done. Good luck. I'd will be glad to know about the results.
Generally, it cannot.
One reason why is that applets tend to be ran within security constrained environments, which means that they are denied the ability to open server sockets.
There are ways around such a restriction, basically you can specify a special security policy for the applet, or run it in a special unconstrained container; but why bother when you can just port the contents of your application into a standard servlet, or even a stand-alone server?
Some background information.
- Running a java server on localhost
- Running a webserver on localhost
I would like a webpage to have a 'server status' feature which lets me know whether the server is running or not. My question, what is the best way to do this?
When I launch the java server, I write a flag in the database to signify that it is running.
Javascript/PHP sockets to try and bind on the same port. (Not sure if possible yet)
Shell script to locate the program in the task list.
Thanks!
When I launch the java server, I write
a flag in the database to signify that
it is running.
would not be of much help if the server should segfault.
Maybe have a look at http://mmonit.com/monit/
what is pretty much what you are looking for
I suspect the simplest method is simply for your web service (backend) to try and connect to the port that your server is running on, and provide an automatically refreshing page that reports this status. If your server goes down then you'll get an faster notification than if you're polling (say) the process table.
Of course the fact that you can connect to the port doesn't really give you an indication of whether it's working other than it's opened a port (e.g. it may have no resources etc. to service requests) but it's a start.