Fastest way to pass messages?

[Chris]

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.

 

[Knute Johnson]

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.

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.

 

[Daniel Pitts]

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.

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.

 

[Chris]

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.

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.

 

[Mark Rafn]

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?

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.

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.

 

[Daniel Pitts]

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.

 

[Patrick May]

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?

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

 

[Chris Smith]

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.