J
T
The Ghost In The Machine
In comp.lang.java.advocacy, John Bailo
<[email protected]>
wrote
Congratulations; you've coded a self-denial-of-service attack to your server.
I've seen this before, admittedly. Google Maps is using the
Microsoft.XMLDOM object but their code is extremely messy to look at.
Your server is using a slightly different approach.
A better structuring of the problem would have keystroke validation
on the client side (e.g., a checksum on charge cards) and the completed
request would then have a more or less guaranteed valid request,
though there's only so much the client can in fact do.
In short, treat network transmissions as very costly.
<[email protected]>
wrote
Congratulations; you've coded a self-denial-of-service attack to your server.
I've seen this before, admittedly. Google Maps is using the
Microsoft.XMLDOM object but their code is extremely messy to look at.
Your server is using a slightly different approach.
A better structuring of the problem would have keystroke validation
on the client side (e.g., a checksum on charge cards) and the completed
request would then have a more or less guaranteed valid request,
though there's only so much the client can in fact do.
In short, treat network transmissions as very costly.
J
John Bailo
The said:In comp.lang.java.advocacy, John Bailo
<[email protected]>
wrote
Congratulations; you've coded a self-denial-of-service attack to your server.
I've seen this before, admittedly. Google Maps is using the
Microsoft.XMLDOM object but their code is extremely messy to look at.
Your server is using a slightly different approach.
A better structuring of the problem would have keystroke validation
on the client side (e.g., a checksum on charge cards) and the completed
request would then have a more or less guaranteed valid request,
though there's only so much the client can in fact do.
In short, treat network transmissions as very costly.
Well, yes, but these are the days of broadband and bittorrents.
Shouldn't the web catch up and break away from the GET/POST global
transaction into pages with many tiny connections open?
T
The Ghost In The Machine
In comp.lang.java.advocacy, John Bailo
<[email protected]>
wrote
RFC792 - ICMP header, 36 bytes
RFC791 - IP header, 24+ bytes
RFC793 - TCP header, 24 bytes
unknown - 12 byte dual-MAC
For purposes of this illustration I'm using tcpdump on
a simple telnet <hostname> 80, and issuing the request
"manually".
The state diagram in figure 6 illustrates the transmission.
The client sends a 74-byte message just to open a socket
(CTL=SYN). The server responds with a 78-byte response.
The sender sends a 66-byte message, and both sides are
now in ESTABLISHED state. That's 218 bytes and we've
not really done anything yet.
Now we can send a request. For purposes of this test I
sent a simple request: 'GET / HTTP/1.0\n\n'. This is 16
bytes, but to send it the packet size is encapsulated,
resulting in a packet size of 82 bytes.
The server responds with a 66-byte response. I'm not sure
precisely what it is, but the client sends a 68-byte response,
which results in two packets; the first is a 66-byte response,
and the second is a 480-byte response -- the header. However,
66 bytes of this 480-byte packet is TCP+IP+other such overhead.
So far:
16 bytes sent has resulted in 288 bytes over-the-wire from
the client. 414 bytes of the header response (of which part
seems to be a transparent proxy we use here at $EMPLOYER)
has resulted in 690 bytes over-the-wire from the server.
Payload? What payload? I've yet to *see* any payload, just
the HTTP headers! I've already spent more than half a kilobyte!
To be sure, on a high-speed network that's not as bad as
on a serial line, but from an efficiency standpoint I've
seen better.
I happen to know that 12 bytes of this is a dual pair of
MAC addresses (and in fact if one looks carefully at the
sniffed output and at the results of /sbin/tcpdump one
can see them). I also see an IP header and a TCP header.
But that only accounts for 60 bytes. To be sure, RFC791
specifies that options may be of variable length.
But lessee, I've sent 1 request of 16 bytes and have
received *nothing but overhead*: some of it's IP, some
of it TCP, some of it HTTP. The payload proper is still
pending, and I'm going to have to spend at least 60 bytes
of overhead to get him...maybe on both sides.
Costly? What do you think?
IPv6 will make it worse, though it's possible they'll optimize
some of this -- but there's only so much they can in fact
optimize.
<[email protected]>
wrote
RFC792 - ICMP header, 36 bytes
RFC791 - IP header, 24+ bytes
RFC793 - TCP header, 24 bytes
unknown - 12 byte dual-MAC
For purposes of this illustration I'm using tcpdump on
a simple telnet <hostname> 80, and issuing the request
"manually".
The state diagram in figure 6 illustrates the transmission.
The client sends a 74-byte message just to open a socket
(CTL=SYN). The server responds with a 78-byte response.
The sender sends a 66-byte message, and both sides are
now in ESTABLISHED state. That's 218 bytes and we've
not really done anything yet.
Now we can send a request. For purposes of this test I
sent a simple request: 'GET / HTTP/1.0\n\n'. This is 16
bytes, but to send it the packet size is encapsulated,
resulting in a packet size of 82 bytes.
The server responds with a 66-byte response. I'm not sure
precisely what it is, but the client sends a 68-byte response,
which results in two packets; the first is a 66-byte response,
and the second is a 480-byte response -- the header. However,
66 bytes of this 480-byte packet is TCP+IP+other such overhead.
So far:
16 bytes sent has resulted in 288 bytes over-the-wire from
the client. 414 bytes of the header response (of which part
seems to be a transparent proxy we use here at $EMPLOYER)
has resulted in 690 bytes over-the-wire from the server.
Payload? What payload? I've yet to *see* any payload, just
the HTTP headers! I've already spent more than half a kilobyte!
To be sure, on a high-speed network that's not as bad as
on a serial line, but from an efficiency standpoint I've
seen better.
I happen to know that 12 bytes of this is a dual pair of
MAC addresses (and in fact if one looks carefully at the
sniffed output and at the results of /sbin/tcpdump one
can see them). I also see an IP header and a TCP header.
But that only accounts for 60 bytes. To be sure, RFC791
specifies that options may be of variable length.
But lessee, I've sent 1 request of 16 bytes and have
received *nothing but overhead*: some of it's IP, some
of it TCP, some of it HTTP. The payload proper is still
pending, and I'm going to have to spend at least 60 bytes
of overhead to get him...maybe on both sides.
Costly? What do you think?
IPv6 will make it worse, though it's possible they'll optimize
some of this -- but there's only so much they can in fact
optimize.
S
Silvio Bierman
The Ghost In The Machine said:
Nice analysis. You are obviously correct in stating that a communication
roundtrip costs more than meets the casual eye.
However, an Ajax-like approach can actually result in less communication
costs. We have built our own HTML application framework based on a similar
idea over the last years. The application is initially loaded once using a
standard browser GET after which the page "manages itself" by exchanging
user events (actually, JS events) with the server-side application where
component level event listeners are called and page updates (delta's) are
collected and sent back to the page. There a small piece of generic JS that
was also responsible for transmitting the events picks up the delta's and
updates the page.
Agreed, if you send every JS event to the server you will fill up the net.
But the framework separates JS events in three categories by default,
allowing the application to selectively change the status of specific events
for specific components:
status=PURGE: default, ignore the event (actually, don't event mention it in
the HTML)
status=DELAYED: collect the event but buffer it locally in the JS on the
page for later transmission
status=IMMEDIATE: collect it and send it to the server along with all
previous DELAYED events
Only an event with status=IMMEDIATE will result in a communication
roundtrip. All events are sent to the server and processed in the correct
order. The delta's are collected while the listeners are called (totally
transparent to the application code) and sent back to the page where the
updates are performed.
The interesting thing is that this way only events that would normally
(traditional GET/POST HTML apps) have resulted in a FORM transmission or any
other type of page/frame refresh are set to IMMEDIATE (anchor clicks, menu
selections etc). Since the pages are usually updated locally only (delta's)
the amount of data exchanged is much smaller than an average HTML page.
The huge advantage is that on the application side we get a Swing like
programming model with component/event level listeners allowing full
compositional logic with embedding self-managing components.
We get tree components, tab components, splitter components, etc and
application level utility components which can be combined into more complex
components aso. just like when programming in Swing. Only we get a
zero-client-install browser interface and the luxury of HTML layout
management (instead of all the crummy Swing layout managers), decent fonts
etc.
Performance of these applications is a lot better than "normal" web
applications which is even more noticable when the communication channel is
slow, like i.e. an old 33K6 modem.
After 10+ years of Windows, Swing and plain-HTML level application
development, the last two years we experience a development speedup factor
of 2-3 when compared to any of the previous techniques used.
The idea behind AJAX is not bad at all. I just don't think it is a very good
framework they built on top.
Regards,
Silvio Bierman