Fastest way to pass messages?

Thread view:

Chris - 06 Apr 2007 02:50 GMT

Our app needs to have a central computer send a message to several other
computers, and then gather a response from each. This has got to happen
hundreds of times per second (not necessarily synchronously). Each
message is just an array of bytes, usually less than 100 bytes on the
way out and less than 8K on the way back.

What's the fastest, most efficient way to do it? RMI? Jini? JMS? REST?
Raw sockets?

I expect that some would say raw sockets, but my guess is that one or
more of the others might be nearly as fast and have other advantages as
well. Any advice is appreciated.

Reply to this Message

Knute Johnson - 06 Apr 2007 03:46 GMT

> Our app needs to have a central computer send a message to several other
> computers, and then gather a response from each. This has got to happen
[quoted text clipped - 8 lines]
> more of the others might be nearly as fast and have other advantages as
> well. Any advice is appreciated.

If the computers are all on the same local network I would think that
UDP would be reliable enough and it is very fast.

I'm not clear on your bandwidth requirements but 100 messages/second *
8KB/message is 800KB/sec. If that is each computer and you said several
computers and hundreds of times per second then you are talking a lot of
data.

4 computers * 400 msgs/sec/computer * 8KB/msg = 12,800KB/sec or
102,400kb/sec or about 100Mb/sec.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Daniel Pitts - 06 Apr 2007 19:06 GMT

I think you're going about this wrong...
Do what is *easiest* first (not most efficient).
If its NOT fast enough. Figure out why (don't guess or speculate,
*measure*), and then complicate your code only when necessary.

Without knowing more about your problem domain, I would be loathed to
suggest one technology over another.

Reply to this Message

Chris - 06 Apr 2007 21:46 GMT

>> Our app needs to have a central computer send a message to several other
>> computers, and then gather a response from each. This has got to happen
[quoted text clipped - 16 lines]
> Without knowing more about your problem domain, I would be loathed to
> suggest one technology over another.

This is extremely not helpful. If you don't know anything, please don't
respond.

Advice about how to write code in general is patronizing, and in this
case, completely misplaced. The problem domain is crystal clear.

Reply to this Message

Mark Rafn - 06 Apr 2007 23:18 GMT

>>> Our app needs to have a central computer send a message to several other
>>> computers, and then gather a response from each. This has got to happen
>>> hundreds of times per second (not necessarily synchronously). Each
>>> message is just an array of bytes, usually less than 100 bytes on the
>>> way out and less than 8K on the way back.

>>> What's the fastest, most efficient way to do it? RMI? Jini? JMS? REST?
>>> Raw sockets?

We need more information.

Do you have latency requirements (i.e. you always want a response under 50ms,
or is it ok to take 5 seconds once in awhile)?

Reliability (are lost messages important, do you need to transact anything
with a message send or acknowledge)?

Is this bursty or stable traffic?

Does sequence of delivery matter?

How sensitive are you really when you say "fastest"? Will you trade some
programmer or debugging ease for a little bit slower response?

>>> I expect that some would say raw sockets, but my guess is that one or
>>> more of the others might be nearly as fast and have other advantages as
>>> well. Any advice is appreciated.

That's why you need to be specific. All of the technologies you list, and
dozens more can handle your stated requirements on reasonable hardware (which
you also didn't mention). Pick the one that fits your unstated requirements.

>> Without knowing more about your problem domain, I would be loathed to
>> suggest one technology over another.

>This is extremely not helpful. If you don't know anything, please don't
>respond.

This is extremely rude. If you don't ask specific questions and you don't
want help on what to ask, please don't post in the first place.

>Advice about how to write code in general is patronizing, and in this
>case, completely misplaced. The problem domain is crystal clear.

It is patronizing. And you asked a question general enough that it's
justified to patronize you a bit. Be more specific and get more specific
answerd.

Raw UDP sockets will be fastest for unreliable transmission, but once you
build a transactional retry system over it, you've lost most of the speed.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>

Reply to this Message

Patrick May - 07 Apr 2007 00:58 GMT

>>>> Our app needs to have a central computer send a message to
>>>> several other computers, and then gather a response from
[quoted text clipped - 20 lines]
> How sensitive are you really when you say "fastest"? Will you trade
> some programmer or debugging ease for a little bit slower response?

Excellent qualifying questions. I'd add:

- Is the number of clients static or variable?
- What are your failover and recovery requirements for both the
server and clients?
- Do all clients have to reply before processing the next
message?
- Do you need to save the requests and responses for reporting or
aggregation?
- Will this system have to scale in the future?
- What extensibility requirements do you foresee?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Reply to this Message

Daniel Pitts - 06 Apr 2007 23:52 GMT

> >> Our app needs to have a central computer send a message to several other
> >> computers, and then gather a response from each. This has got to happen
[quoted text clipped - 19 lines]
> This is extremely not helpful. If you don't know anything, please don't
> respond.

I don't know everything, but many people would point out that I know
something, therefor I can respond if I choose.

> Advice about how to write code in general is patronizing, and in this
> case, completely misplaced. The problem domain is crystal clear.

Actually, your problem domain is NOT crystal clear.
If your messages would make sense as a method call: String
something(int a, String b); then I might suggest using RMI.

If the queries are more complicated, I might suggest a web-service
approach.

If your queries and results are likely to evolve over time, I might
suggest using XML.

You're question was "which is fastest". You'll find on this group
that most responses to that form of question are "Why do you need
fastest?"

The advice I gave you can save you and your company time and money,
much more than knowing which is more "efficient". If you wanted the
most efficient application, write the damned thing in assembly. If
you want a working and low-bug-rate application, make it work before
making it fast.

Reply to this Message

Chris Smith - 07 Apr 2007 01:50 GMT

> This is extremely not helpful. If you don't know anything, please don't
> respond.

If you think this is good advice, perhaps you should take it.

> Advice about how to write code in general is patronizing, and in this
> case, completely misplaced. The problem domain is crystal clear.

Crystal clear to you, perhaps (though I'm not convinced). Not to anyone
else, though. The answer to the first question you asked is blindingly
obvious: of course using plain sockets will be faster than using any
other library built on top of sockets. Your last paragraph appeared to
be asking for some discussion involving other advantages besides speed;
but I guess not, because you insulted the first person who said anything
in that direction.

Well, to each his (or her) own. I will try to avoid responding to your
posts from now on.

Signature

Chris Smith

Reply to this Message

Fastest way to pass messages?

Free Magazines