Re: Opinions on application design?
- From: "Branimir Maksimovic" <bmaxa@xxxxxxxxxx>
- Date: 4 Oct 2005 16:44:20 -0700
Monique Y. Mudama wrote:
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2005-10-03, Roedy Green penned:
> >
> > There are three most likely approaches:
> >
> > 1. http get. The response can be text or binary, uncompressed or
> > compressed. This is the garden variety way to solve it. I would not
> > suggest adding extra layers like XML, SOAP etc since your app is so
> > simple that all you would be doing is adding overhead. You don't
> > need the flexibility.
> >
> > 2. raw sockets. This assumes a user has an extended session with
> > many requests one after the other. It also assumes you don't have
> > all that many users potentially connected at once.
> >
> > 3. datagrams. Presumes responses are short. You must handle lost
> > packets yourself. Particularly useful if there is peer to peer
> > communication.
> >
>
> Why would sockets in particular have more trouble with many users than
> other methods?
Because ,obviously, that have somthing to do how java handles
them:)
First : http is text based application protocol
It goes through sockets.(he probaby meant web server )
Second: raw sockets provide raw network protocol access
(probably he meant SOCK_STREAM type of sockets, not raw sockets)
SOCK_STREAM types provide reliable two-way sequenced communication
with connections.
Third: is connectionless unreliable socket protocol
with maximum data packet size limit. (good for dns requests,
streaming of music, video, etc)
HTTP server uses SOCK_STREAM type(you all know
famous port #80).
>
> This isn't just an idle question; we're looking at switching an applet
> from using http to raw sockets because of the HTTP limit on the number
> of simultaneous connections to a single server.
It is not just a matter of connections,
but also a http server task dispatch strategy.
It hase to *run something* for every connection.
Because of that, using facilities of http_server as substitution
for dedicated front end for database is not good.
If ,dedicated, in this case, server can for example serialize
writes from different connections in one request and provide multi
threaded accesses for read operations (eg one writer thread / 4 reader
threads on two cpu system, this is 5 connections to mysql) while
accepting as many connections as possible on the other end.
(this solution is ok for mysql's table level lock and thread per
connection strategy, it will survive several thousand external
connections).
This is impossible to achieve if task and connections
are handled by http server.
Ok it can be done if http_server is just used to pass through
connections to server, but this has large overhead and limitations
of running scripts in a web server.
Greetings, Bane.
.
- Prev by Date: Re: retrieve data from a jTable
- Next by Date: Re: resize JTable
- Previous by thread: Re: Opinions on application design?
- Next by thread: Re: Opinions on application design?
- Index(es):
Relevant Pages
|
