Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #108668 > unrolled thread

Re: OT: limit number of connections from browser to my server?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: OT: limit number of connections from browser to my server? Chris Angelico <rosuav@gmail.com> - 2016-05-17 02:15 +1000
    Re: OT: limit number of connections from browser to my server? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-16 16:34 +0000
      Re: OT: limit number of connections from browser to my server? Chris Angelico <rosuav@gmail.com> - 2016-05-17 02:52 +1000
        Re: OT: limit number of connections from browser to my server? Steven D'Aprano <steve@pearwood.info> - 2016-05-17 12:50 +1000
          Re: OT: limit number of connections from browser to my server? Chris Angelico <rosuav@gmail.com> - 2016-05-17 13:02 +1000
            Re: OT: limit number of connections from browser to my server? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-17 15:22 +1000
          Re: OT: limit number of connections from browser to my server? Gene Heskett <gheskett@wdtv.com> - 2016-05-17 01:26 -0400
          Re: OT: limit number of connections from browser to my server? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-17 16:59 +0000
            Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-17 18:42 +0000
              Re: OT: limit number of connections from browser to my server? Paul Rubin <no.email@nospam.invalid> - 2016-05-29 22:03 -0700
                Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-31 15:31 +0000
            Re: OT: limit number of connections from browser to my server? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-05-17 18:28 -0400
            Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-18 13:58 +0000
      Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-16 19:19 +0000
        Re: OT: limit number of connections from browser to my server? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-16 20:09 +0000
        Re: OT: limit number of connections from browser to my server? Paul Rubin <no.email@nospam.invalid> - 2016-05-16 13:41 -0700
          Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-16 21:32 +0000
            Re: OT: limit number of connections from browser to my server? Paul Rubin <no.email@nospam.invalid> - 2016-05-29 22:00 -0700

#108668 — Re: OT: limit number of connections from browser to my server?

On Tue, May 17, 2016 at 2:06 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
> So, when a browser wants to load a page that has the main html file, a
> css file, a javascript library or two, and a few icons and background
> bitmaps, they browser opens up a half-dozen SSL connections in
> parallel.
>
> That's fine when the server is Facebook's server farm.
>
> But when it's a small embedded device running at 40MHz with a
> single-threaded web server and software crypto, it turns a 2-second
> page load time into a 15-second page load time.
> ...
> So now I'm going to set up a simple Python HTTP server to try some
> other approaches:
>
>   1) Only allow the listening socket to accept 1 connection at a time.
>
>   2) Accept the TCP connection, but don't allow the SSL handshaking to
>      start on the "extra" connections.
>
>   3) ???
>
>   4) Profits!
>
> Any ideas?

If your server is single-threaded, it ought to be processing only one
connection at a time anyway. Are you sure parallel connections are the
problem here?

The solution might actually be to move all your static files
elsewhere. Slap 'em up onto github.io or something, and then the
browser is free to make all the parallel connections it likes; your
embedded device can just serve the stuff that actually varies
(presumably the main HTML file). I know that isn't what you asked for,
but it's something to consider :)

ChrisA

[toc] | [next] | [standalone]

#108670

Chris Angelico wrote:

> On Tue, May 17, 2016 at 2:06 AM, Grant Edwards
> <grant.b.edwards@gmail.com> wrote:
>> So, when a browser wants to load a page that has the main html file, a
>> css file, a javascript library or two, and a few icons and background
>> bitmaps, they browser opens up a half-dozen SSL connections in
>> parallel.
>>
>> That's fine when the server is Facebook's server farm.
>>
>> But when it's a small embedded device running at 40MHz with a
>> single-threaded web server and software crypto, it turns a 2-second
>> page load time into a 15-second page load time.
>> ...
>> So now I'm going to set up a simple Python HTTP server to try some
>> other approaches:
>>
>>   1) Only allow the listening socket to accept 1 connection at a time.
>>
>>   2) Accept the TCP connection, but don't allow the SSL handshaking to
>>      start on the "extra" connections.
>>
>>   3) ???
>>
>>   4) Profits!
>>
>> Any ideas?
>
> If your server is single-threaded, it ought to be processing only one
> connection at a time anyway. Are you sure parallel connections are the
> problem here?
>
> The solution might actually be to move all your static files
> elsewhere. Slap 'em up onto github.io or something, and then the
> browser is free to make all the parallel connections it likes; your
> embedded device can just serve the stuff that actually varies
> (presumably the main HTML file). I know that isn't what you asked for,
> but it's something to consider :)
>
> ChrisA

Oooof.  Not to be rude, Chris, but your "software guy" is showing. 
Grant's got the right of it; if you're shipping a box with an RJ-45 and
a webpage, and you want the customer to be able to always make it
work, then it needs to be a self-contained entity.  The belief that your
external dependancies will always be there is why leftpad was able to
break everything, and why Google just bricked a bunch of people's
expensive Revolv Hubs.

The problem with processing one connection at a time is that TCP
doesn't transmit your data when you ask it to, it holds onto it for a
couple hundred ms to make sure you didn't have anything else to say on
that socket.  Those build up, and you get horrific page load times
because the system is having to single track all the files.

Grant, the bad news is that I know this because our firware guy had
_exactly_ this problem, with exactly your scenario, about a month ago.
http, not https, but the problem remains the same but for some heavy
math. After a lot of door knocking, poking, prodding, and hoping, the
conclusion he reached was that what you want can't be done, and he had
to gut and redesign the web server to support parallel connections. 
Turned a 45 second page load into south of one, but it wasn't pretty and
chewed up a bunch of RAM.  We had 256K to play in; I'm assuming you've
got closer to 32K.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#108673

On Tue, May 17, 2016 at 2:34 AM, Rob Gaddi
<rgaddi@highlandtechnology.invalid> wrote:
>> The solution might actually be to move all your static files
>> elsewhere. Slap 'em up onto github.io or something, and then the
>> browser is free to make all the parallel connections it likes; your
>> embedded device can just serve the stuff that actually varies
>> (presumably the main HTML file). I know that isn't what you asked for,
>> but it's something to consider :)
>>
>> ChrisA
>
> Oooof.  Not to be rude, Chris, but your "software guy" is showing.
> Grant's got the right of it; if you're shipping a box with an RJ-45 and
> a webpage, and you want the customer to be able to always make it
> work, then it needs to be a self-contained entity.  The belief that your
> external dependancies will always be there is why leftpad was able to
> break everything, and why Google just bricked a bunch of people's
> expensive Revolv Hubs.

I agree, but I also make no apology for suggesting the option of
getting someone else to do some of the work. In this case, it can be
rejected for the exact reason you cite (dependencies are a cost, and
in this case way too high a cost), and that's fine and correct.
Ultimately, if the job gets done, everything else is implementation
detail, with consequences - and I know a lot of people who'll
willingly sacrifice "reliability in the face of an internet connection
outage" in favour of "less than fifteen second response time". Hence
my suggestion, albeit couched in "might be" and "something to
consider". :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#108706

On Tue, 17 May 2016 02:52 am, Chris Angelico wrote:

> On Tue, May 17, 2016 at 2:34 AM, Rob Gaddi
> <rgaddi@highlandtechnology.invalid> wrote:
>>> The solution might actually be to move all your static files
>>> elsewhere. Slap 'em up onto github.io or something, and then the
>>> browser is free to make all the parallel connections it likes; your
>>> embedded device can just serve the stuff that actually varies
>>> (presumably the main HTML file). I know that isn't what you asked for,
>>> but it's something to consider :)
>>>
>>> ChrisA
>>
>> Oooof.  Not to be rude, Chris, but your "software guy" is showing.
>> Grant's got the right of it; if you're shipping a box with an RJ-45 and
>> a webpage, and you want the customer to be able to always make it
>> work, then it needs to be a self-contained entity.  The belief that your
>> external dependancies will always be there is why leftpad was able to
>> break everything, and why Google just bricked a bunch of people's
>> expensive Revolv Hubs.

Schadenfreude is a beautiful emotion :-)

"Yes, let's put a critical requirement of our business in the hands of a
third party with absolutely *no* obligations to us, and no government
oversight. What could *possibly* go wrong???"


> I agree, but I also make no apology for suggesting the option of
> getting someone else to do some of the work. In this case, it can be
> rejected for the exact reason you cite (dependencies are a cost, and
> in this case way too high a cost), and that's fine and correct.
> Ultimately, if the job gets done, everything else is implementation
> detail, with consequences - and I know a lot of people who'll
> willingly sacrifice "reliability in the face of an internet connection
> outage" in favour of "less than fifteen second response time". 

How can you not serve a web page over your LAN in 15s?

I mean, you could *almost* do it by hand, copying the files onto a USB stick
and walking them across the room in 15 seconds. Maybe 30.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#108708

On Tue, May 17, 2016 at 12:50 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> How can you not serve a web page over your LAN in 15s?
>
> I mean, you could *almost* do it by hand, copying the files onto a USB stick
> and walking them across the room in 15 seconds. Maybe 30.

Don't forget to encrypt them by hand.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108714

On Tuesday 17 May 2016 13:02, Chris Angelico wrote:

> On Tue, May 17, 2016 at 12:50 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> How can you not serve a web page over your LAN in 15s?
>>
>> I mean, you could *almost* do it by hand, copying the files onto a USB stick
>> and walking them across the room in 15 seconds. Maybe 30.
> 
> Don't forget to encrypt them by hand.

For that I'll use rot13, twice for extra security.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#108716

On Monday 16 May 2016 23:02:07 Chris Angelico wrote:

> On Tue, May 17, 2016 at 12:50 PM, Steven D'Aprano <steve@pearwood.info> 
wrote:
> > How can you not serve a web page over your LAN in 15s?
> >
> > I mean, you could *almost* do it by hand, copying the files onto a
> > USB stick and walking them across the room in 15 seconds. Maybe 30.
>
> Don't forget to encrypt them by hand.
>
> ChrisA

Yes, rot13, twice for good measure...


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#108747

Steven D'Aprano wrote:

> On Tue, 17 May 2016 02:52 am, Chris Angelico wrote:
>
>> On Tue, May 17, 2016 at 2:34 AM, Rob Gaddi
>> <rgaddi@highlandtechnology.invalid> wrote:
>>>> The solution might actually be to move all your static files
>>>> elsewhere. Slap 'em up onto github.io or something, and then the
>>>> browser is free to make all the parallel connections it likes; your
>>>> embedded device can just serve the stuff that actually varies
>>>> (presumably the main HTML file). I know that isn't what you asked for,
>>>> but it's something to consider :)
>>>>
>>>> ChrisA
>>>
>>> Oooof.  Not to be rude, Chris, but your "software guy" is showing.
>>> Grant's got the right of it; if you're shipping a box with an RJ-45 and
>>> a webpage, and you want the customer to be able to always make it
>>> work, then it needs to be a self-contained entity.  The belief that your
>>> external dependancies will always be there is why leftpad was able to
>>> break everything, and why Google just bricked a bunch of people's
>>> expensive Revolv Hubs.
>
> Schadenfreude is a beautiful emotion :-)
>
> "Yes, let's put a critical requirement of our business in the hands of a
> third party with absolutely *no* obligations to us, and no government
> oversight. What could *possibly* go wrong???"
>
>
>> I agree, but I also make no apology for suggesting the option of
>> getting someone else to do some of the work. In this case, it can be
>> rejected for the exact reason you cite (dependencies are a cost, and
>> in this case way too high a cost), and that's fine and correct.
>> Ultimately, if the job gets done, everything else is implementation
>> detail, with consequences - and I know a lot of people who'll
>> willingly sacrifice "reliability in the face of an internet connection
>> outage" in favour of "less than fifteen second response time". 
>
> How can you not serve a web page over your LAN in 15s?
>
> I mean, you could *almost* do it by hand, copying the files onto a USB stick
> and walking them across the room in 15 seconds. Maybe 30.
>

Simple, because embedded web servers running on toy microprocessors are
HARD.  When you're trying to work with whatever browser the customer may
have, you have no control over the number of simultaneous connections 
it will try to make to your box.  If you don't allow those connections
it can cause huge stalls by forcing the TCP layer to time out.  If you
do, in Grant's case, it forces you to perform tons of expensive
public-key crypto on a 40 MHz processor (which, hmmm, external memory
bus, ~40 MHz... Coldfire?).

A lot of things you can take for granted on a compute monster (like a
Chromebook or Atom based laptop) get much more complicated when you're
resource constrained.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#108749

On 2016-05-17, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>
>> How can you not serve a web page over your LAN in 15s?
>>
>> I mean, you could *almost* do it by hand, copying the files onto a
>> USB stick and walking them across the room in 15 seconds. Maybe 30.
>
> Simple, because embedded web servers running on toy microprocessors are
> HARD.

40MHz with multiple MB of RAM is pretty high-end in my book.  I've
worked on projects where the clock speed was in KHz, the supply
current was measrued in micro-Amps, and there were a few KB of RAM.
Of course you don't try to do TCP and SSL on something like that.

> When you're trying to work with whatever browser the customer may
> have, you have no control over the number of simultaneous connections 
> it will try to make to your box.  If you don't allow those connections
> it can cause huge stalls by forcing the TCP layer to time out.  If you
> do, in Grant's case, it forces you to perform tons of expensive
> public-key crypto on a 40 MHz processor (which, hmmm, external memory
> bus, ~40 MHz... Coldfire?).

The 40MHz one is a Samsung ARM7TDMI.  There's a newer model with a
133MHz Cortex-M3.  For most things it's 2-3 times faster than the
ARM7, but the ARM7 has an I/D cache and the M3 doesn't.  So there are
few highly localized tasks where there's not a lot of difference.

> A lot of things you can take for granted on a compute monster (like
> a Chromebook or Atom based laptop) get much more complicated when
> you're resource constrained.

And that's what keeps me paid. :)

-- 
Grant Edwards               grant.b.edwards        Yow! I know th'MAMBO!!
                                  at               I have a TWO-TONE CHEMISTRY
                              gmail.com            SET!!

[toc] | [prev] | [next] | [standalone]

#109252

Grant Edwards <grant.b.edwards@gmail.com> writes:
> The 40MHz one is a Samsung ARM7TDMI.  There's a newer model with a
> 133MHz Cortex-M3.  

Another thing occurs to me-- do you have to support older browsers?
Newer TLS stacks support elliptic curve public key, which should be a
lot faster on those cpus than RSA/DHE is.

[toc] | [prev] | [next] | [standalone]

#109284

On 2016-05-30, Paul Rubin <no.email@nospam.invalid> wrote:
> Grant Edwards <grant.b.edwards@gmail.com> writes:
>
>> The 40MHz one is a Samsung ARM7TDMI.  There's a newer model with a
>> 133MHz Cortex-M3.  
>
> Another thing occurs to me-- do you have to support older browsers?
> Newer TLS stacks support elliptic curve public key, which should be a
> lot faster on those cpus than RSA/DHE is.

Thanks, that's a good ideal.  Our stack doesn't support elliptic
curve, but there's an newer version available tht does. There have
been some changes to the API, but the effort might be worth it.

-- 
Grant Edwards               grant.b.edwards        Yow! My mind is a potato
                                  at               field ...
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#108753

On Tue, 17 May 2016 18:42:12 +0000 (UTC), Grant Edwards
<grant.b.edwards@gmail.com> declaimed the following:


>40MHz with multiple MB of RAM is pretty high-end in my book.  I've

	How about a 68040 running at 30MHz (when not running in a dual system
with a 20MHz board) <G> If it wasn't for the massive NVM needs I'd almost
think a TI TIVA connected launchpad might be faster <G>

	No idea where they are buying the processor... they had to update the
board as an FPGA was no longer available...

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#108762

On 2016-05-17, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Tue, 17 May 2016 18:42:12 +0000 (UTC), Grant Edwards
><grant.b.edwards@gmail.com> declaimed the following:
>
>
>>40MHz with multiple MB of RAM is pretty high-end in my book.  I've
>
> 	How about a 68040 running at 30MHz (when not running in a dual system
> with a 20MHz board) <G>

The '040 even supports hardware floating point and virtual memory (and
it has I/D cache). That's livin' large!  We've got brand-new products
coming out later this year without all that fancy stuff.

-- 
Grant Edwards               grant.b.edwards        Yow! I haven't been married
                                  at               in over six years, but we
                              gmail.com            had sexual counseling every
                                                   day from Oral Roberts!!

[toc] | [prev] | [next] | [standalone]

#108686

On 2016-05-16, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:

> Grant, the bad news is that I know this because our firware guy had
> _exactly_ this problem, with exactly your scenario, about a month ago.
> http, not https, but the problem remains the same but for some heavy
> math. After a lot of door knocking, poking, prodding, and hoping, the
> conclusion he reached was that what you want can't be done,

Bummer.

> and he had to gut and redesign the web server to support parallel
> connections.

Mine does (in effect) support parallel connections.  With HTTP it all
works fine: browser opens 4-5 connections in parallel; sends requests
on all of them; responses come back on all of them.  A few of the
connections then get reused for additional requests, and so on.

> Turned a 45 second page load into south of one, but it wasn't pretty and
> chewed up a bunch of RAM.  We had 256K to play in; I'm assuming you've
> got closer to 32K.

I've actually got plenty of RAM.  I just can't afford the CPU time it
takes to do the public-key crypto stuff that happens each time an SSL
connection starts up.

I'm hoping that if I refuse additional connections (or stall them
before the SSL handshake), I can convince the browser to make use of
extant connections.

However, in my case, there are some cases where a connection can't be
re-used because the server doesn't know how big the reply is going to
be and the only way to identy "end of reply" is for the server to
close the connection.  In theory I can fix that by adding support to
the server for chunked encoding in the cases where the reply size is
unknown.  But that won't do me any good if the browser opens 4 more
connections before it's even seen the response from the first one.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a RELIGIOUS
                                  at               EXPERIENCE ... and I don't
                              gmail.com            take any DRUGS

[toc] | [prev] | [next] | [standalone]

#108694

Grant Edwards wrote:

> On 2016-05-16, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>
>> Grant, the bad news is that I know this because our firware guy had
>> _exactly_ this problem, with exactly your scenario, about a month ago.
>> http, not https, but the problem remains the same but for some heavy
>> math. After a lot of door knocking, poking, prodding, and hoping, the
>> conclusion he reached was that what you want can't be done,
>
> Bummer.
>
>> and he had to gut and redesign the web server to support parallel
>> connections.
>
> Mine does (in effect) support parallel connections.  With HTTP it all
> works fine: browser opens 4-5 connections in parallel; sends requests
> on all of them; responses come back on all of them.  A few of the
> connections then get reused for additional requests, and so on.
>
>> Turned a 45 second page load into south of one, but it wasn't pretty and
>> chewed up a bunch of RAM.  We had 256K to play in; I'm assuming you've
>> got closer to 32K.
>
> I've actually got plenty of RAM.  I just can't afford the CPU time it
> takes to do the public-key crypto stuff that happens each time an SSL
> connection starts up.
>
> I'm hoping that if I refuse additional connections (or stall them
> before the SSL handshake), I can convince the browser to make use of
> extant connections.
>
> However, in my case, there are some cases where a connection can't be
> re-used because the server doesn't know how big the reply is going to
> be and the only way to identy "end of reply" is for the server to
> close the connection.  In theory I can fix that by adding support to
> the server for chunked encoding in the cases where the reply size is
> unknown.  But that won't do me any good if the browser opens 4 more
> connections before it's even seen the response from the first one.
>

That's easy then.  Redesign the product to outsource the crypto to a
custom-designed FPGA which pretends to be DDR on the memory bus to
maximize data throughput.  By the time you're done with all of that, the
HTTP standards should have evolved to obviate the original problem.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#108697

Grant Edwards <grant.b.edwards@gmail.com> writes:
> I've actually got plenty of RAM.  I just can't afford the CPU time it
> takes to do the public-key crypto stuff that happens each time an SSL
> connection starts up.

I think you should only have to do that once, then use TLS session
resumption for additional connections.  There is also something called
TLS-PSK in TLS 1.3.  Do you mind saying the application, and what
clients you have to support?  What TLS stack are you using?  There is
generally also a way to configure browsers to limit the number of
outgoing connections.

I'll probably be meeting with some TLS experts tomorrow night for
unrelated reasons, so I can ask them about this if you want.

[toc] | [prev] | [next] | [standalone]

#108700

On 2016-05-16, Paul Rubin <no.email@nospam.invalid> wrote:

> Grant Edwards <grant.b.edwards@gmail.com> writes:

>> I've actually got plenty of RAM.  I just can't afford the CPU time
>> it takes to do the public-key crypto stuff that happens each time
>> an SSL connection starts up.
>
> I think you should only have to do that once, then use TLS session
> resumption for additional connections.

Thanks, I'll look into that -- I've seen the term before, but that's
about it.

Is it something the server tells the client to do?

And more to the point, will all popular browsers do it?

> There is also something called TLS-PSK in TLS 1.3.  Do you mind
> saying the application, and what clients you have to support?

The application is something proprietary running on proprietary
hardware (32-bit ARM processor running a typical RTOS and a
BSD-derived network stack).  The web server is a heavily modified
version of GoAhead 2.something.

I have to support the usual suspect list of browsers: IE, Firefox,
Chrome, Safari.

> What TLS stack are you using?

It's not an open-source one.  Beyond that, I can't really say.

> There is generally also a way to configure browsers to limit the
> number of outgoing connections.

I can't ask the browser user to change settings.

> I'll probably be meeting with some TLS experts tomorrow night for
> unrelated reasons, so I can ask them about this if you want.

-- 
Grant Edwards               grant.b.edwards        Yow! I want you to MEMORIZE
                                  at               the collected poems of
                              gmail.com            EDNA ST VINCENT MILLAY
                                                   ... BACKWARDS!!

[toc] | [prev] | [next] | [standalone]

#109251

Grant Edwards <grant.b.edwards@gmail.com> writes:
>> then use TLS session resumption for additional connections.
> Thanks, I'll look into that -- I've seen the term before, but that's
> about it.
> Is it something the server tells the client to do?
> And more to the point, will all popular browsers do it?

Sorry for the slow response.  I don't remember the exact mechanism but
yes, I believe session response goes way back and should be in all
browsers.  Remember that SSL was first invented to run in browsers on
PC's of the era, that were almost as slow then as the embedded board
you're using now.

> The application is something proprietary running on proprietary
> hardware (32-bit ARM processor running a typical RTOS and a

Can you say the CPU specifics (architecture, clock speed)?  There
might be some optimized crypto code around for it.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web