Re: Adding a web interface to an exisiting server.
- From: "David" <FlyLikeAnEagle@xxxxxxxxxx>
- Date: Tue, 19 Sep 2006 11:07:31 GMT
Hello,
On Sun, 17 Sep 2006 16:39:56 UTC, "" <newptcai@xxxxxxxxx> wrote:
David,
Thanks a lot for your explanation. Can we discuss this problem a
little more?
Certainly.
Efficiency and using slower access methods to a database don't have
to be mutually exclusive. You just need a secondary process/thread
to store the data in memory to the database.
We did save data in memory to db whenever it changes. And when the
server restarts, it fetch all the data from db to memory ( we do have
lots of memory), and since then, it never reads the db. What you
guess it right, we have a secondary thread doing the writing to db job.
It sounds like you have several distinct parts that comprise your
system. There doesn't need to be a large amount of magic to make
the parts communicate more efficiently.
Yeah, now we did have a private protocol to manipulate the sever. I
designed it. The current model is like this:
Client GUI <==private protocol====> server = write change to db
=> db
The private protocol is very very clumsy and complicated as we have
many tables and the tables have many columns.
Okay, your communications have grown into a reasonably complicated
solution that probably breaks from time to time when certain
details are not considered.
So I don't want to use the private protocol any more in the second
version of the server program.
What I want is like this:
Server <=== SOAP/XML RPC => Web Server <== db
| |
----------------------------------
or:
Web Server <== > db <=> Server
I prefer the second model here since the db likely always
exists. Depending on how the interactions work in the first
diagram the Server could be down when the Web Server was
down for maintenance. Of course the later solution may
also have its limits when the db needs a schema change.
I'll make a brief comment on SOAP/XML RPC. It can be a
useful solution when it actually solves a problem without
creating other problems. XML does a nice job of allowing
your protocol to define the contents, provided that both
communicators understand the items. XML may have a great
deal of overhead depending on your particular data or
the need to rework either of the servers. One obvious
complexity is the data tends to grow. With many tables
and columns and rows this can be a problem for communication
challenged systems. [We had one at work that the team did
something like that and seemed to spend an inordinate
amount of time revising the communications later so that
compression was added for slow links and security was added
to satisfy customers.] I tend to prefer taking the simple
route most of the time. For instance, I favor simple
protocols or TLD where appropriate. I use XML on the
fringes where public tools might be easier to find.
You mention that the communication protocol is rather
complicated now. You are considering SOAP/XML as a solution
to the problem. Each end will probably have the same
complexity as it does today. Will your design really solve
the problem it intends to? e.g. Changing the underlying
schema or notifications will become more easy to implement
and reliable as the project grows.
There were technologies similar to and perhaps better than
SOAP/XML before. It all depends on what makes sense for
your needs today. It sounds like your primary problem
is that you need to revise how the project is grown so
that managing the information is easier to do and that
time can be spent adding functionality instead of
retesting or debugging problems. Is that a fair
assessment?
There is nothing wrong with home-grown protocols. You
understand your problem, so hopefully the solution mirrors
your actual needs.
We are using mysql as db and communicating to it with capi.
The server is written in c .
These are good tools.
David
========================================
By the way, let me describe the mechanism of our sever.
As I have written, it's written in c and running on linux. But it has
it has it's own thread communication method : message queue.
Each thread has a message queue and they insert MSG to each others' MSG
queue to communicate. A MSG must be processed until next MSG could be
processed.
In this way, these threads could be easily serperated to many different
machines.
Of course, in my case, it does not make any senses. But we are a big
company and we were forced to use this platform.
David wrote:
Hello,
On Sat, 16 Sep 2006 18:44:22 UTC, "" <newptcai@xxxxxxxxx> wrote:
Hi all
In most cases, web application has a database for it's own use. It
allow users to change data and present data to user. It dose not have
to know any other programs but the database.
That is one method.
I hope my problem would be that easy. I have to a server what
manipulating lots of network devices. It saves its data to a db which
allows it to recovery from collapse or power off. But it keeps all the
data it needed in memory to achieve higher efficiency.
Efficiency and using slower access methods to a database don't have
to be mutually exclusive. You just need a secondary process/thread
to store the data in memory to the database.
And I have to give user an web interface which allow them to change the
data and so change the behavior of the server.
it would be very easy to create an web interface for changing data in a
db. But, how can I notify the server that the data has been changed as
it never fetches data from db.
Perhaps it should. Another method is the reverse of what was suggested
above -- have a process/thread update the memory from the database.
I thought there are 3 ways to solve this problem, but I am not sure
which one is better.
1. Do not cache any data in my server, just fetch it from database on
demand. Perhaps this is not efficient enough.
That depends on your server and the technology you choose to use.
It sounds like you are already using a memory resident cgi application.
Find a way to connect the database to your data stored in memory.
2. Design a protocol to notify the server that data has been changed.
It sounds like you have several distinct parts that comprise your
system. There doesn't need to be a large amount of magic to make
the parts communicate more efficently.
What do u think about it? Is any better choices?
Find out what you actually need in terms of performance and design.
Then find the components you need to make the desired system. It
may take some trial and error to find a good balance between
simplicity and development cost.
David
.
- References:
- Prev by Date: download various nice Ebooks on .Net,Visual Basics, ASP, PHP
- Next by Date: Re: Help
- Previous by thread: Re: Adding a web interface to an exisiting server.
- Next by thread: Computer Vitals - Your Online Computer Helpline
- Index(es):
Relevant Pages
|
