Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Scalability of Multiple SSL Sockets (Java 1.4.2)

Reply
Thread Tools

Scalability of Multiple SSL Sockets (Java 1.4.2)

 
 
Hal Vaughan
Guest
Posts: n/a
 
      04-02-2006
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
 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      04-02-2006
Hal Vaughan wrote:

> 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/.../Selector.html

-- chris


 
Reply With Quote
 
 
 
 
Hal Vaughan
Guest
Posts: n/a
 
      04-02-2006
Chris Uppal wrote:

> Hal Vaughan wrote:
>
>> 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/.../Selector.html
>
> -- chris


It doesn't work with SSL, though.

Hal
 
Reply With Quote
 
Daniel Dyer
Guest
Posts: n/a
 
      04-02-2006
On Sun, 02 Apr 2006 17:52:30 +0200, Hal Vaughan <(E-Mail Removed)>
wrote:

> Chris Uppal wrote:
>
>> Hal Vaughan wrote:
>>
>>> 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/.../Selector.html
>>
>> -- chris

>
> 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.

--
Daniel Dyer
http://www.dandyer.co.uk
 
Reply With Quote
 
Hal Vaughan
Guest
Posts: n/a
 
      04-02-2006
Daniel Dyer wrote:

> On Sun, 02 Apr 2006 17:52:30 +0200, Hal Vaughan <(E-Mail Removed)>
> wrote:
>
>> Chris Uppal wrote:
>>
>>> Hal Vaughan wrote:
>>>
>>>> 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/.../Selector.html
>>>
>>> -- chris

>>
>> 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?


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
 
Reply With Quote
 
EJP
Guest
Posts: n/a
 
      04-03-2006
Hal Vaughan wrote:

> 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).
 
Reply With Quote
 
Daniel Dyer
Guest
Posts: n/a
 
      04-03-2006
On Mon, 03 Apr 2006 01:51:09 +0200, Hal Vaughan <(E-Mail Removed)>
wrote:
> 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.

--
Daniel Dyer
http://www.dandyer.co.uk
 
Reply With Quote
 
Hal Vaughan
Guest
Posts: n/a
 
      04-03-2006
Daniel Dyer wrote:

> On Mon, 03 Apr 2006 01:51:09 +0200, Hal Vaughan <(E-Mail Removed)>
> wrote:
>> 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 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.)

>> 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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
javax.net.ssl Sockets and OKing self-signed certificates Richard Maher Java 8 09-28-2007 12:16 AM
javax.net.ssl Sockets and OKing self-signed certificates Richard Maher Javascript 2 09-06-2007 02:18 PM
Sockets: Fine Regularly, Bad With SSL Hal Vaughan Java 8 03-31-2006 11:24 AM
University of Minnesota Selects Cisco Storage Area Network for Scalability, Reliability technology_post@yahoo.com Cisco 0 03-30-2006 05:37 PM
Secure Sockets Layer (SSL) Version... John Smith ASP .Net 1 01-12-2006 06:53 PM



Advertisments