corba or sockets?
Fernando Rodríguez
I have to comunicate a lisp process with a c++ app and I was
considering corba or using sockets. Both are rather new to me, so wich one
would you recommend and why? O:-)
TIA
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Marc Battyani
"Fernando Rodríguez" <spa...@must.die> wrote in message
news:hriqvscgjd0pcql56...@4ax.com...
> Hi!
>
> I have to comunicate a lisp process with a c++ app and I was
> considering corba or using sockets. Both are rather new to me, so wich one
> would you recommend and why? O:-)
I use sockets. It works well and is quite simpler to use than corba and the
performance is very good over a 100 Mbit LAN. You just have to be able to do
both sides of the communication. With Corba you can inter-operate with
already existing Corba enabled software. You also need a lisp with Corba.
Marc Battyani
Philip Lijnzaad
Fernando> Hi!
Fernando> I have to comunicate a lisp process with a c++ app and I was
Fernando> considering corba or using sockets. Both are rather new to me, so wich one
Fernando> would you recommend and why? O:-)
Unless the communication involves simple but big data (kind of like ftp,
say), use CORBA, by a very long shot.
Philip
--
Time passed, which, basically, is its job. -- Terry Pratchett (in: Equal Rites)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Erik Naggum
| I have to comunicate a lisp process with a c++ app and I was
| considering corba or using sockets. Both are rather new to me, so
| wich one would you recommend and why? O:-)
CORBA is already badly designed, so if you are new to sockets and
protocol design (which you will get yourself into), the likelihood
that you, too, will design your protocol badly is so high that it is
probably better to go with CORBA.
If you are very dedicated, you will probably spend a few months just
getting up to speed with protocol design before you can do something
that is not a total drag, and upwards of a year to get it fully
right. Such braindamaged disasters as HTTP (any version) would not
have been possible if there were at least some reasonably accessible
material on how to do these things.
Security problems in protocols are so common and so hard to avoid
that you _really_ don't want to expose yourself to the process of
learning by doing.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Eric Marsden
provides a design for developing distributed applications and useful
services such as naming, trading, event propagation. CORBA is
therefore large, and will require time to understand.
>>>>> "mb" == Marc Battyani <Marc.B...@fractalconcept.com> writes:
mb> With Corba you can inter-operate with already existing Corba
mb> enabled software. You also need a lisp with Corba.
CLORB (under development, but already useful, particularly for
client-side CORBA) works with CMUCL, CLISP, SBCL and ACL. Available
under GNU LGPL.
<URL:http://clorb.sourceforge.net/>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Erik Naggum
| Unless the communication involves simple but big data (kind of like ftp,
| say), use CORBA, by a very long shot.
Really? I'd use CORBA for fairly simple stuff and roll my own if I
get above a fairly low complexity threshold, but I know I'm about
three orders of magnitude better at protocol design than the CORBA
team could ever dream of becoming. For instance, CORBA is a single-
threaded protocol, with lock-step properties where you wait for the
answer before you continue with the next transaction. This is of
course a consequence of serial computations and CORBA being a very,
very slow way of doing serial computations on disjoint processes and
processors.
With all this hoopla about multi-threading and other uses for real
and pseudo-parallelism, you might expect people to think through the
multi-threading implications of their protocols. The hardware folks
are gung-ho about _real_ parallelism, trying very hard to answer the
demand for faster on-chip communication, but then what do we get in
the software world? People who use all this new hardware power only
to wait for ages for incoming data before they turn around _real_
fast to send something that did not even need to wait for that value
and then proceed to wait for ages, again, only because the protocol
is designed by a committee of morons?
If you cannot deal with multiple objects "on the wire" and are not
using the bandwidth at full throttle even while you _are_ waiting
for something to come in, you are not programming in the dynamic,
networked world of the new millennium. (How's that for buzzwords?)
E.g, how many applications do you know which continue to work just
as well if you move one of the computers 3000 miles away? Do you
think CORBA handles this situation well? From what I have seen, the
application grinds to a virtual stand-still. Latencies higher than
a few millisecond cause all sorts of interesting behavior in modern
software. It's pretty pathetic that such things are touted as
workable solutions.
Fernando Rodríguez
>* Fernando Rodríguez <spa...@must.die>
>| I have to comunicate a lisp process with a c++ app and I was
>| considering corba or using sockets. Both are rather new to me, so
>| wich one would you recommend and why? O:-)
>
> CORBA is already badly designed, so if you are new to sockets and
> protocol design (which you will get yourself into), the likelihood
> that you, too, will design your protocol badly is so high that it is
> probably better to go with CORBA.
What's so wrong about corba?
Marc Battyani
news:31818958...@naggum.net...
> * Fernando Rodríguez <spa...@must.die>
> | I have to comunicate a lisp process with a c++ app and I was
> | considering corba or using sockets. Both are rather new to me, so
> | wich one would you recommend and why? O:-)
>
> CORBA is already badly designed, so if you are new to sockets and
> protocol design (which you will get yourself into), the likelihood
> that you, too, will design your protocol badly is so high that it is
> probably better to go with CORBA.
>
> If you are very dedicated, you will probably spend a few months just
> getting up to speed with protocol design before you can do something
> that is not a total drag, and upwards of a year to get it fully
> right. Such braindamaged disasters as HTTP (any version) would not
> have been possible if there were at least some reasonably accessible
> material on how to do these things.
There are lots of text based protocols (ok it's a weak argument they could
all be just crap). Why are you against simple lisp reader friendly text
based protocols when 1) the task is really easy and 2) you master both sides
of the communication?
I drive lots of measuring instruments from Lisp and they all have text based
protocols.
> Security problems in protocols are so common and so hard to avoid
> that you _really_ don't want to expose yourself to the process of
> learning by doing.
By security do you mean cryptographic security or protocol security (fail
safe, resync, etc.)?
If it's the former then SSL can be used. Or do you know security holes in
SSL ?
Marc Battyani
Michael Livshin
> Really? I'd use CORBA for fairly simple stuff and roll my own if I
> get above a fairly low complexity threshold, but I know I'm about
> three orders of magnitude better at protocol design than the CORBA
> team could ever dream of becoming. For instance, CORBA is a single-
> threaded protocol, with lock-step properties where you wait for the
> answer before you continue with the next transaction. This is of
> course a consequence of serial computations and CORBA being a very,
> very slow way of doing serial computations on disjoint processes and
> processors.
do you imply that it *was* possible to come up with a better wire
protocol for CORBA as it is, or that the whole concept of "remote
procedure call" (i.e. the CORBA semantics) is not an adequate
abstraction in situations involving non-trivial network latencies?
I would agree with the latter, I guess...
--
(only legal replies to this address are accepted)
newsgroup volume is a measure of discontent. -- Erik Naggum
Erik Naggum
| There are lots of text based protocols (ok it's a weak argument they
| could all be just crap). Why are you against simple lisp reader
| friendly text based protocols when 1) the task is really easy and 2)
| you master both sides of the communication?
Can you back up and at least explain _how_ you arrived at the
assumptions that underlie your questions?
Erik Naggum
| do you imply that it *was* possible to come up with a better wire
| protocol for CORBA as it is, or that the whole concept of "remote
| procedure call" (i.e. the CORBA semantics) is not an adequate
| abstraction in situations involving non-trivial network latencies?
Yes, that the remote procedure call model is fundamentally flawed.
It is, however, possible to do remote procedure calls intelligently,
but it requires a programming language that can deal with unfinished
computations and actually calculate with them for a while. This is
not terribly difficult stuff, but not trivial, either.
Erik Naggum
| What's so wrong about corba?
Almost everything. I have sketched how in a response to a another
article. CORB's only redeeming quality is that it is a standard, of
sorts, and facilitates communication with library-based "tools".
Real programmers want something that actually works efficiently, too.
Fernando Rodríguez
BTW, what about ILU? O:-)
>Hi!
>
> I have to comunicate a lisp process with a c++ app and I was
>considering corba or using sockets. Both are rather new to me, so wich one
>would you recommend and why? O:-)
//-----------------------------------------------
Eric Marsden
en> For instance, CORBA is a single- threaded protocol, with
en> lock-step properties where you wait for the answer before you
en> continue with the next transaction.
this is no longer true. While the standard CORBA communication model
is synchonous twoway (the client thread which sends the request is
blocked while waiting for the server to answer), several other types
of communication are possible:
* oneway invocations, where the client doesn't wait for a response
* deferred synchonous, where the client invokes a request and can
poll the server later to see whether a response is available (this
is available by using the dynamic invocation interface)
* over EventChannels specified by the CORBA Event Service, or the more
recent Notification Service. The Event Channel mediates
communication between consumers and suppliers, and allows push,
pull, push/pull and pull/push interactions.
* asynchronous method invocations provided by CORBA Messaging, either
by polling or with callbacks. [This has been specified fairly
recently, so isn't supported by all implementations.]
See <URL:http://www.iona.com/hyplan/vinoski/> for some excellent
papers on these subjects (from the C/C++ Users Journal :-).
Tim Bradshaw
>
> Yes, that the remote procedure call model is fundamentally flawed.
>
> It is, however, possible to do remote procedure calls intelligently,
> but it requires a programming language that can deal with unfinished
> computations and actually calculate with them for a while. This is
> not terribly difficult stuff, but not trivial, either.
>
I think this is yet another one of those cases where most software
people (clearly not Erik) are living in the world of the PDP11.
Hardware people spend all their time dealing with these issues -- just
look at the design of a modern processor, which is dealing exactly
this kind of thing. Memory access is essentially just like RPC. The
PDP11 approach is: issue a request, wait for a result, do something,
issue another one and so on. Modern machines have to deal with huge
memory latencies, and so do something much more complex and
interesting involving multiple outstanding requests, caching of
requests, and speculatively executing code for which all the
prerequisites are not yet known. And they can make this stuff work on
machines with multiple processors, all doing their own caching, and in
a context where `fixes' to the algorithms can often not be made
because they're cast in silicon.
And to cap it all, they manage to make the resulting design *look like
a PDP11* because they know that's all SW people can deal with!
So I suppose either SW people will have to work out that you can't
program network protocols as if they were memory access on a PDP11, or
some *really* cool HW people will manage to make RPC look like is *is*
memory access on a PDP11!
--tim
William Deakin
> So I suppose either SW people will have to work out that you can't
> program network protocols as if they were memory access on a PDP11, or
> some *really* cool HW people will manage to make RPC look like is *is*
> memory access on a PDP11!
Is this because most SW people are stupid and most HW people are clever?
Is this why SW people like java, C++ ... and not Common Lisp?
;)w
Fernando Rodríguez
> It is, however, possible to do remote procedure calls intelligently,
> but it requires a programming language that can deal with unfinished
> computations and actually calculate with them for a while. This is
> not terribly difficult stuff, but not trivial, either.
Could you elaborate on this, with some example, please?
Jason Trenouth
> * Philip Lijnzaad <lijn...@ebi.ac.uk>
> | Unless the communication involves simple but big data (kind of like ftp,
> | say), use CORBA, by a very long shot.
>
> Really? I'd use CORBA for fairly simple stuff and roll my own if I
> get above a fairly low complexity threshold, but I know I'm about
> three orders of magnitude better at protocol design than the CORBA
> team could ever dream of becoming. For instance, CORBA is a single-
> threaded protocol, with lock-step properties where you wait for the
> answer before you continue with the next transaction. This is of
> course a consequence of serial computations and CORBA being a very,
> very slow way of doing serial computations on disjoint processes and
> processors.
>
> ...
CORBA calls are synchronous by default. The call site effectively blocks
waiting for a reply even for operations returning void and containing no 'out'
or 'inout' arguments. Part of the reason for this is probably because system
exceptions may be thrown by ORB, or by the Object Adaptor on the serverside (eg
OBJECT_NOT_EXIST), even when no user exceptions have been declared.
Client code that isn't interested in waiting for potential failures can spawn a
thread in which to make the call or could declare the operation as 'oneway' in
IDL.
The CORBA community have recently been defining new asynchronous calling
mechanisms for themselves:
http://cgi.omg.org/cgi-bin/doc?orbos/98-05-05
__Jason
Marc Battyani
> * "Marc Battyani" <Marc.B...@fractalconcept.com>
> | There are lots of text based protocols (ok it's a weak argument they
> | could all be just crap). Why are you against simple lisp reader
> | friendly text based protocols when 1) the task is really easy and 2)
> | you master both sides of the communication?
>
> Can you back up and at least explain _how_ you arrived at the
> assumptions that underlie your questions?
May be it's an English issue (from me) but when you write:
> CORBA is already badly designed, so if you are new to sockets and
> protocol design (which you will get yourself into), the likelihood
> that you, too, will design your protocol badly is so high that it is
> probably better to go with CORBA.
My understanding of this is that "CORBA is bad" and "you probably won't do
better so use it anyway"
This is why I ask you if you still think so if the protocol is a simple lisp
reader friendly text based protocol when 1) the task is really easy and 2)
you master both sides of the communication?
Marc Battyani
Paolo Amoroso
> right. Such braindamaged disasters as HTTP (any version) would not
> have been possible if there were at least some reasonably accessible
> material on how to do these things.
Could you please mention a few examples of well designed protocols that are
worth studying? Thanks in advance.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Will Hartung
Marc Battyani wrote in message <8tkf8h$4ka$1...@reader1.fr.uu.net>...
>
>May be it's an English issue (from me) but when you write:
>
>> CORBA is already badly designed, so if you are new to sockets and
>> protocol design (which you will get yourself into), the likelihood
>> that you, too, will design your protocol badly is so high that it is
>> probably better to go with CORBA.
>
>My understanding of this is that "CORBA is bad" and "you probably won't do
>better so use it anyway"
>
>This is why I ask you if you still think so if the protocol is a simple
lisp
>reader friendly text based protocol when 1) the task is really easy and 2)
>you master both sides of the communication?
The issue that you are missing is that there is more to a protocol than
simply the data being transmitted. There's also the timing and sequencing
details. You can certainly have a very sophisticated and complicated
protocol based on either a Lisp text stream or a binary stream.
HTTP is, essentially, a text based protocol, but that fact alone doesn't
make it good or bad, just readable to humans.
Regards,
Will Hartung
(will.h...@havasint.com)
Erik Naggum
| Could you elaborate on this, with some example, please?
Why?
Consider the "normal" way people implement streams, with a single
buffer that is over-written with new data as the reading crashes
into the right buffer wall and then continues from the left end of
the buffer. This is not smart in a modern world.
Instead of crashing into a buffer wall, have several buffers. Ask
the operating system to fill them for you while you're more or less
busy processing the data already read, as in "asynchronously". The
operating system is doing a decent job of predicting your linear
progression through the file, anyway, so it sort of works to crash
into buffer walls and get first aid from the operating system and
get back on your feet, but it is far from optimal, and no matter
what you do with that system call, it at _least_ has to copy the
buffer contents from system memory to user memory, which is also
probably at a really bad alignnment for hardware support for such
copying. Several page-aligned buffers can cause I/O to occur at the
operating system's discretion, copying is not needed if the
operating system can map the page directly into user space, and you
can scan through a large file in no time compared to these false
stops and starts as you crash into buffer walls.
Consider the sending of mail to someone with SMTP. As long as you
have well-defined state transitions that are (fairly) independent,
send a whole bunch of commands down the wire and match the responses
to the requests sent instead of waiting for each response by itself.
Consequence? _Dramatic_ speedup when sending to many recipients.
In normal human life, you don't get paralyzed and die if you don't
an answer to a question, but (carefully) go on with assumptions
because you probably have a pretty good idea what kind of answer
you're going to get. Just how many code paths could you possibly
walk down depending on the answer? Do them all! You certainly have
the time while the bits trickle across the globe.
Erik Naggum
| this is no longer true.
I appreciate the update.
I _still_ think CORBA sucks, though.
Erik Naggum
| Is this because most SW people are stupid and most HW people are clever?
| Is this why SW people like java, C++ ... and not Common Lisp?
Is that a SW person or a HW person asking?
Erik Naggum
| This is why I ask you if you still think so if the protocol is a
| simple lisp reader friendly text based protocol when 1) the task is
| really easy and 2) you master both sides of the communication?
The likelihood that novices will do worse than CORBA is still very,
very high. Look at how people design their input languages from
simple files that are under total programmer control, and often they
blow it so bad applications crash and burn, a missed version update
causes serious bit rot, and changing your mind about something means
you lose a _lot_ of old information. Using Lisp for this does not
really help.
No networked task is really easy. If it were, you wouldn't be doing
it. If you're still doing it, how could that possibly impact any
decision on how to design protocols for tasks _worth_ doing?
I actually _favor_ Lisp-based protocols, but not because "it's text,
so it's easy" is even close to relevant (it isn't -- syntax is an
important issue to humans -- it is _not_ important to representing
the data), but because it means I have a stable and proven framework
to work from.
It is actually quite important to realize that just because it's
text doesn't make it any less fraught with all the dangers of other
network protocols. For one thing, network communications is subject
to a failure modes that novices never consider. Even with the best
of checksum algorithms, you _may_ get rotten data once in a while.
Deadlocks may occur whether you use a hariy binary protocol or a
Lisp-based protocol. All these things are unlikely to happen if you
run on a local machine, and they don't happen if you work within the
same memory. (Unless you run without error correcting memory, of
course, but then again, if you do that, you have already proclaimed
to the world that you don't care, so nobody else should bother.)
Marc Battyani
"Will Hartung" <will.h...@havasint.com> wrote in message
news:8tkk7...@news1.newsguy.com...
Sure. I do agree with all this and this is why I think that for easy tasks
(T.B.D.) it's better to use sockets than CORBA (or COM for M$ fans). When I
don't write Lisp, I write VHDL where I implement lots of (fast!) protocols
at the bit/hardware level. Well, it seems that I should communicate in VHDL
or Lisp rather than English today...
Another communication channel I used between applications is mapped memory +
system events. This gives the fastest communication I could achieve between
2 applications.
Marc Battyani
Marc Battyani
"William Deakin" <w.de...@pindar.com> wrote in message
news:39FDA10C...@pindar.com...
Now that HW is written in VHDL (SW) the frontier is becoming rather fuzzy.
Lisp has been very present in the electronics CAD software industry and the
standard file format (EDIF) should look familiar here. See yourself, here
are the first lines of an EDIF file...
(edif time_sim
(edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(status
(written
(timestamp 2000 5 24 12 0 29)
(program "Xilinx NGD2EDIF" (version "C.18"))
(comment "Command line: -w -v fndtn testus.nga time_sim.edn ")))
(external SIMPRIMS
(edifLevel 0)
(technology (numberDefinition
(scale 1 (E 1 -12) (unit TIME))))
(cell x_and3
(cellType GENERIC)
(view view_1
(viewType NETLIST)
(interface
(port IN0
(direction INPUT))
(port IN1
(direction INPUT))
(port IN2
(direction INPUT))
(port OUT
(direction OUTPUT))
....
Looks like HW guys don't need XML though I'm sure some brilliant SW guy will
explain some day that these file should be written in XML to be used by
C#.NET...
When this arrives we could start to have to reboot, several time per day,
our watches, radio receivers, phones, lifts, flash lights,...
Marc Battyani
Marc Battyani
Ok, I fully agree with this. I missed the emphasis you made on the
difficulty of designing a correct protocol, and I thought you were against
using Lisp based protocols.
Marc Battyani
Erik Naggum
| Could you please mention a few examples of well designed protocols
| that are worth studying? Thanks in advance.
TCP and IPv4 are _very_ good protocols. (I don't know enough about
IPv6 to rate it.) The telecommunications protocols used on the
gigabit trunks and on the long-haul high-speed interconnects are
amazing feats of science. Of the really, _really_ large protocol
suites, I find ITU's Signalling System #7, the Digital Subscriber
Signalling System, and the Integrated Digital Services Network
protocols as well-designed as they are complex. The Telecom people
have probably done some of the best work there is in protocol
design. Just take a look at how they started out with very low
speeds, like 300 bps, but over time managed to squeeze 56kbps
through the feeble phone lines that were not upgraded, then got DSL
to work across that same old copper wire. Impresses me, anyway.
FTP and SMTP are well-designed and fairly small protocols, too.
(Small does not mean quick-and-dirty: If you spend less than 3
months implementing a server or client for either of them, however,
you're doing it wrong, as almost every implementation that is not
regarded as a huge monstrosity are.)
As an example of a very good way of separating abstractions and
representation, ASN.1 and its encoding rules are worth a study, such
as what is done with SNMP.
Finally, if you don't know X.25, you don't know packet exchange, but
it's _real_ old, now, and probably doesn't bring anything directly
applicable to people who think in streams implemented on top of
record-based protocols, except what _not_ to do with streams and
when it really does make sense to use records.
_Very_ few of the recent application-level Internet protocols are
worth the paper they aren't published on. The sheer lack of design
behind the protocol that is _actually_ at work in the MIME cruft is
astonishing, but trying to track that braindamaged piece of shit
from its inception to its current specification level through the
numerous RFCs will tell you what a few over-sized egos who had no
clue what they were doing can do to a conceptually _very_ simple
thing: Wrap various objects in a textual representation.
On the other hand, the Network Time Protocol was done by people who
really cared and also who managed to keep the dolts out of the way.
Jon S Anthony
>
> * Philip Lijnzaad <lijn...@ebi.ac.uk>
> | Unless the communication involves simple but big data (kind of like ftp,
> | say), use CORBA, by a very long shot.
>
> Really? I'd use CORBA for fairly simple stuff and roll my own if I
> get above a fairly low complexity threshold, but I know I'm about
> three orders of magnitude better at protocol design than the CORBA
The real question should be whether you believe your new protocol adds
real value to what it is you are producing. If you are in the
protocol business this is obvious. If you are in something else
entirely and only need to make use of protocols, it is highly unlikely
that the time spent on inventing yet another one will be of any real
value for your project/product.
CORBA is _not_ anything like the best distributed object protocol that
one could define - probably a legacy of the C++ mentality of most of
the original vendors involved. However, it _does_ work rather well
for many scenarios - most any that someone not in the protocol tool
business would care about.
> team could ever dream of becoming. For instance, CORBA is a single-
> threaded protocol, with lock-step properties where you wait for the
> answer before you continue with the next transaction. This is of
> course a consequence of serial computations and CORBA being a very,
> very slow way of doing serial computations on disjoint processes and
> processors.
This has not been true since at least CORBA 2.0. That's not to say
that you have "true" asynchronous communication (request and asynch
notification of completion) out of the box (certainly not in any of
the ORBs we've used). However, you certainly have one way calls
(basically datagrams...) and can also use of these, or more likely
synchronous "posts", to get this. We've done this here and the
results are actually _very_ good.
The nice thing about using CORBA to do this is that it at least
eliminates all the marshalling and unmarshalling of data items
(primitive and structured) in a platform independent way. Unless your
business is really line protocols or something similar, rolling your
own here with sockets is just a distracting waste of resources.
> the software world? People who use all this new hardware power
> only to wait for ages for incoming data before they turn around
> _real_ fast to send something that did not even need to wait for
> that value and then proceed to wait for ages, again,
Only if you don't make use of threads in making the calls in the first
place. If each call is a thread, the "waiting for the synchronous
reply" is irrelevant. Most ORBs are multithreaded and can easily
handle this.
> E.g, how many applications do you know which continue to work just
> as well if you move one of the computers 3000 miles away? Do you
> think CORBA handles this situation well? From what I have seen, the
Well we have done it at 2000 miles and the results were basically
"instantaneous" (well under a second). Using straight X was death.
Using HTTP was (of course) worse than death.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Erik Naggum
| The real question should be whether you believe your new protocol adds
| real value to what it is you are producing. If you are in the
| protocol business this is obvious. If you are in something else
| entirely and only need to make use of protocols, it is highly unlikely
| that the time spent on inventing yet another one will be of any real
| value for your project/product.
I disagree with this assessment. It is the same argument that can
be made for something overly complex and badly implemented, like
SGML, It has also been touted as solving problems that people would
not be able to solve cheaper by themselves. That was just plain
false. Similar problems crop up with other committee products that
have tried to solve overly broad and thus non-existing problems
instead of trying to solve real problems of real complexity.
How much effort does it take a good system designer to come up with
something better than XML for any _particular_ purpose? If he
grasps the good and useful qualities of SGML, a simplified syntax,
slightly general tools, etc, can be written in a fairly short amount
of time, and it costs less to develop, maintain, and use than a
full-fledged SGML system does, because, importantly, SGML's full
generality has surpassed the point where additional features bring
nothing but more costs than benefits to the equation.. A particular
markup language (or something similar) is also easier to learn for
someone who has _not_ spent much too much time studying the original
-- like one one who is only moderately familiar with the original.
| CORBA is _not_ anything like the best distributed object protocol
| that one could define - probably a legacy of the C++ mentality of
| most of the original vendors involved. However, it _does_ work
| rather well for many scenarios - most any that someone not in the
| protocol tool business would care about.
Precisely, but having designed a few protocols that have been in
wide use for over a decade each, just how much effort do you think
it is to design new ones? The reason protocol design is hard is
that people are told not to do it, and thus do not investigate the
issues involved. This also leads to incredibly bad protocols in
use, because the users are told they are too hard to understand.
| This has not been true since at least CORBA 2.0.
I'm "happy" to hear that.
| The nice thing about using CORBA to do this is that it at least
| eliminates all the marshalling and unmarshalling of data items
| (primitive and structured) in a platform independent way.
You know, this is _not_ a hard problem. It is a hard problem in C++
and the like, but that is because those languages have lost every
trace of the information the compiler had when building the code.
That design mistakes has cost the world _billions_ of dollars. If
you don't make that design mistake, you don't have to worry. I
know, this sounds "too good to be true", but the inability of any
small C++ program to read C++ source code and do useful things with
it is the reason for all these weird data-oriented languages.
| Unless your business is really line protocols or something similar,
| rolling your own here with sockets is just a distracting waste of
| resources.
Well, I have tried both approaches. Have you?
| Only if you don't make use of threads in making the calls in the
| first place. If each call is a thread, the "waiting for the
| synchronous reply" is irrelevant. Most ORBs are multithreaded and
| can easily handle this.
Right. Not my experience. Of course, everything gets better in the
mythical "future", so do stay with CORBA if you have other things to
do while waiting for the synchronous request for more features sees
a response from the CORBA people. (Sorry, a tad rambling here.)
| Well we have done it at 2000 miles and the results were basically
| "instantaneous" (well under a second). Using straight X was death.
| Using HTTP was (of course) worse than death.
How long time do you think you would have spent designing a protocol
that would have been just as good?
Christopher Browne
the artist formerly known as Eric Marsden said:
>>>>>> "en" == Erik Naggum <er...@naggum.net> writes:
>
> en> For instance, CORBA is a single- threaded protocol, with
> en> lock-step properties where you wait for the answer before you
> en> continue with the next transaction.
>
>this is no longer true. While the standard CORBA communication model
>is synchonous twoway (the client thread which sends the request is
>blocked while waiting for the server to answer), several other types
>of communication are possible:
>
> * oneway invocations, where the client doesn't wait for a response
Deprecated, due to the availability of AMI...
> * deferred synchonous, where the client invokes a request and can
> poll the server later to see whether a response is available (this
> is available by using the dynamic invocation interface)
> * over EventChannels specified by the CORBA Event Service, or the more
> recent Notification Service. The Event Channel mediates
> communication between consumers and suppliers, and allows push,
> pull, push/pull and pull/push interactions.
Essentially, these two approaches amount to a _simulation_ of
asynchronous communications by using some sort of "proxy" to manage
the connection. They still use synchronous twoway communications; if
whatever server is sitting there ready to accept the requests can
queue them so they _appear_ async, then you get something that _looks_
async.
Reality doesn't change...
> * asynchronous method invocations provided by CORBA Messaging,
> either by polling or with callbacks. [This has been specified
> fairly recently, so isn't supported by all implementations.]
Are there any non-C++ implementations of AMI? All the documentation
I've seen on AMI has been quite tightly tied to C++...
>See <URL:http://www.iona.com/hyplan/vinoski/> for some excellent
>papers on these subjects (from the C/C++ Users Journal :-).
The thing that is irritating about CORBA is that once you start trying
to get into anything that deviates from "just plain vanilla
synchronous connections," it gets _real_ complex and _real_ strongly
tied to platform-dependancies _real_ fast. They've got a standard for
everything, but only a few that are ubiquitously available.
It's a bit like comparing CL to Scheme; both involve standards; the
problem with Scheme, like CORBA, is that getting Full Functionality
means having to have huge quantities of extensions that don't work
with all the implementaitons. (Contrast with the fact that the SERIES
extension for CL can at least be _hoped_ to work with many CL
implementations...)
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.hex.net/~cbbrowne/corba.html>
"Popularity is the hallmark of mediocrity." --Niles Crane, "Frasier"
William Deakin
> Is that a SW person or a HW person asking?
Clearly a SW person or else I wouldn't be talking about it :)
Peter Vaneynde
> * Fernando Rodríguez <spa...@must.die>
> | I have to comunicate a lisp process with a c++ app and I was
> | considering corba or using sockets. Both are rather new to me, so
> | wich one would you recommend and why? O:-)
>
> CORBA is already badly designed, so if you are new to sockets and
IMHO CORBA is badly designed, and the problems this produces are only
amplified by the legions of C++ "programmers" that want to design
systems using only the knownledge of "Corba in 21 days".
Network programming isn't easy, and using CORBA in a slightly
different way the designers immagined will get you into a world of
pain. But it all appears so easy in the examples people are lured into
a false sense of security...
I think CORBA should be seen as "just" a RPC call round ASN.1, and
people should use its 'oo'-ness as sparingly as possible. Just have a
Server object replying to simple (non-object) commands with simple
(structure) replies. Stick to this and you'll be safe. Ignore the
C++/java people why cry you don't know OOP and want to make everything
an object. Remember that a RPC is inherently slow, so limit the amount
of calls needed to do a typical operation, also (unless you use
advanced stuff, not implemented in the lisp servers AFAIK) objects in
CORBA as horribly costly: they take about 1K of space on the wire and
most deadly of all *the never, ever die*. An object in CORBA, once
created and given out *has* to remain alive for the duration of the
lisp process.
> If you are very dedicated, you will probably spend a few months just
> getting up to speed with protocol design before you can do something
> that is not a total drag, and upwards of a year to get it fully
> right.
Right. Be prepared to junk the first few versions of your code. (or
just give up and leave that project)
> Security problems in protocols are so common and so hard to avoid
> that you _really_ don't want to expose yourself to the process of
> learning by doing.
In my experience people don't care, and I don't expect this to change
soon :-(.
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
mailto:Peter.V...@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961