Scalability of Multiple SSL Sockets (Java 1.4.2)

[Hal Vaughan]

After working on a secure port forwarder, I've realized I could use the same
code for a secure server intended only for my programs, on different
networks, to talk to each other.

I'm thinking of writing a mini-server to go on my web site, which is hosted
by a third party that will take requests from my programs, on different
computers, and return the needed information. I see advantages of this
because I can use keystores to authenticate not only the server for the
client programs, but the server can authenticate and verify who it is
talking to. I also figure (and am willing to be corrected) that Java is
rather secure, and it isn't hard to use error trapping to force the program
to exit (and restart, with a good batch file) if something goes wrong.

The problem is, for different reasons, I need to stick with Java 1.4.2,
which means I cannot use a Selector. As it is, once I use
SSLSocket.accept() to create a socket, I was going to start the handshake
so I'd know quickly if the connection was authorized or not. Connections
would be dropped as soon as they're found to be unauthorized or as soon as
communications are complete. I know one of the big reasons for creating
the Selector object was for scalability. So, on a third party server which
is probably a vm (on Linux), just how many simultaneous connections could
Java easily handle without using a Selector and needing to continuously
check for incoming data on the existing sockets?

Thanks for any help/info/links.

Hal

 

[Chris Uppal]

The problem is, for different reasons, I need to stick with Java 1.4.2,
which means I cannot use a Selector.

Why not ? 1.4.2 includes Selector:

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/Selector.html

-- chris

 

[Hal Vaughan]

Why not ? 1.4.2 includes Selector:

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/Selector.html

-- chris

It doesn't work with SSL, though.

Hal

 

[Daniel Dyer]

It doesn't work with SSL, though.

Turning your original question around, how many concurrent connections do
you need/want to be able to deal with?

How many you can deal with depends on traffic patterns (are the
connections mostly idle, chatty, or maxed out?), the amount of memory
available and the kind of latency you are prepared to accept.

Dan.

 

[Hal Vaughan]

Turning your original question around, how many concurrent connections do
you need/want to be able to deal with?

That's what I'm working with. I don't have a huge number of clients, but at
some point that number could go up. I don't want to write something that
will only handle 2-5 connections and have to re-write it because suddenly I
have 20-25, for example. I'm also looking at the other side of the
question: How many clients could I, with any degree of reason, expect to
log on at the same time. Data download usually takes only 30 seconds, so
it might also be possible to program something in so the receiver can be
sent a "Please wait" message.

I'm still at the exploring stage of this. I like the idea of doing this in
Java, since it'll be a breeze to have the receiver and the website
authenticate each other by keeping their own keystores, but I can also just
use standard Perl CGI with password authentication. I've noticed on my
system, with only 2 threads running in a port forwarder, each reading one
port and writing to the other, if I pull up a game, it runs slower (that's
my unofficial quick test to see what kind of load I have). What I'm
planning is different, though, since after the connection, there's a strict
send-receive-send-receive sequence, which would take less CPU time than
always listening to a socket.

How many you can deal with depends on traffic patterns (are the
connections mostly idle, chatty, or maxed out?), the amount of memory
available and the kind of latency you are prepared to accept.

I'm still working on that. I don't need instant response, but when a client
runs their program and is downloading data, I don't want them waiting long
enough to get impatient. I guess I'm looking for a general idea. Does a
program with different threads, each one listening to a socket require a
lot more resources for each additional thread and socket, or only a small
amount?

I've read that using different threads doesn't scale well, but I guess I'm
just trying to get an idea of where the general line is between light
resource use and heavy.

Hal

 

[EJP]

I've read that using different threads doesn't scale well, but I guess I'm
just trying to get an idea of where the general line is between light
resource use and heavy.

Your problem won't be the threads until you get into thousands, it will
be the N simultaneous handshakes and the crypto operations they require
at the server. At some point you will have to go for a hardware accelerator.

See also http://www.telekinesis.com.au (disclaimer: my product).

 

[Daniel Dyer]

That's what I'm working with. I don't have a huge number of clients,
but at
some point that number could go up. I don't want to write something that
will only handle 2-5 connections and have to re-write it because
suddenly I
have 20-25, for example. I'm also looking at the other side of the
question: How many clients could I, with any degree of reason, expect to
log on at the same time. Data download usually takes only 30 seconds, so
it might also be possible to program something in so the receiver can be
sent a "Please wait" message.

20-25 really won't be a problem. A few hundred will probably be OK. SSL
puts more load on the server, so if your clients all connect at the same
time you have a lot of handshaking to do, which could slow things down
considerably, but that would be the case with non-blocking I/O as well.

I'm still working on that. I don't need instant response, but when a
client
runs their program and is downloading data, I don't want them waiting
long
enough to get impatient. I guess I'm looking for a general idea. Does a
program with different threads, each one listening to a socket require a
lot more resources for each additional thread and socket, or only a small
amount?

If you go with the one thread per socket approach and your code is not
particularly recursive, it may be worth investigating the -Xss JVM option
to keep the memory usage reasonable.

I've read that using different threads doesn't scale well, but I guess
I'm
just trying to get an idea of where the general line is between light
resource use and heavy.

It doesn't scale to tens of thousands of users. The bottle neck is the
number of threads you can comfortably create, which depends largely on
which OS and JVM combination you are using and how much memory you have.

Dan.

 

[Hal Vaughan]

20-25 really won't be a problem. A few hundred will probably be OK. SSL
puts more load on the server, so if your clients all connect at the same
time you have a lot of handshaking to do, which could slow things down
considerably, but that would be the case with non-blocking I/O as well.


If you go with the one thread per socket approach and your code is not
particularly recursive, it may be worth investigating the -Xss JVM option
to keep the memory usage reasonable.

I had never heard of that. I'll have to look into it. (If you're self
taught, it seems you miss a lot of "standard" features because they often
don't show up when you're tracking down what you need.)

It doesn't scale to tens of thousands of users. The bottle neck is the
number of threads you can comfortably create, which depends largely on
which OS and JVM combination you are using and how much memory you have.

When we get completely "up and running", the focus will be on a smaller
number of well paying clients as opposed to many low paying clients.
Several people have said the bottleneck is the handshake. If so, I don't
see that as a huge problem, since that's done once per connection. I am
not sure how much memory I have access to on the server (I'll have to check
next time I'm on it), but even if it scales to 100 users or so, I think it
should work fine.

One other thought comes to mind regarding this: I'm no expert on security.
If I have a program like this running on a server and make sure I catch all
the errors appropriately and exit after them, and have a batch file running
the program that automatically restarts it, am I pretty safe with Java as
far as someone trying to connect and create a stack overflow?

Hal