Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Blocking Connections w/ Java Sockets
- Thread starter PHHeisel
- Start date
sedj
Programmer
- Aug 6, 2002
- 5,610
I believe that's what a firewall is for.
--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software
--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software
Depends on what you mean. client side or server side?
Blocking on a server:
A server socket waiting for incoming effectivly blocks all other incommong connections to a port. If the server socket either refuses to accept or doesn't accept (say server isn't written to handle more than one client at a time, or the server is under stress of a slashdotting or DoS attack) then the port is effectivly blocked because other services wouldn't be able to take incomming connections of that port.
However, what happens isn't the same as hardware firewall -- as the security of the user account under which the service is running would be equal to the security of the service itself not falling over (by falling over I mean stack overflow) under load. While Java's stack is in the JVM, Sun took a lot of effort to make sure that stack overflowers are detected before they occur, and Java stack growing away from kernel memory -- it is still a very real concern.
Effective software firewalls are written closer to the OS to use kernel supported features, and while they may (i don't know) use the method of creating a bunch of server sockets and then not accepting, the method can be more dangerous than not having a firewall.
Client Side
Effectivly, you could potentially open enough out going connections to block other traffic on that port. This would slow down the system and would do nothing for incomming connections.
Java is a highlevel language that is abstracted from the system it runs on. To write a program with the intent to stop traffic on a port, i.e. software firewall, you'd need a higher level language.
A hardware firewall, properly set up, is the best way to go.
[plug=shameless]
[/plug]
Blocking on a server:
A server socket waiting for incoming effectivly blocks all other incommong connections to a port. If the server socket either refuses to accept or doesn't accept (say server isn't written to handle more than one client at a time, or the server is under stress of a slashdotting or DoS attack) then the port is effectivly blocked because other services wouldn't be able to take incomming connections of that port.
However, what happens isn't the same as hardware firewall -- as the security of the user account under which the service is running would be equal to the security of the service itself not falling over (by falling over I mean stack overflow) under load. While Java's stack is in the JVM, Sun took a lot of effort to make sure that stack overflowers are detected before they occur, and Java stack growing away from kernel memory -- it is still a very real concern.
Effective software firewalls are written closer to the OS to use kernel supported features, and while they may (i don't know) use the method of creating a bunch of server sockets and then not accepting, the method can be more dangerous than not having a firewall.
Client Side
Effectivly, you could potentially open enough out going connections to block other traffic on that port. This would slow down the system and would do nothing for incomming connections.
Java is a highlevel language that is abstracted from the system it runs on. To write a program with the intent to stop traffic on a port, i.e. software firewall, you'd need a higher level language.
A hardware firewall, properly set up, is the best way to go.
[plug=shameless]
[/plug]
- Status