If you are at the prototyping stage then I would suggest using regular Java SE (Hotspot) and so how far it gets you. You say "the more real-time it is the better" but I think you mean "the faster it is the better". Whether this needs to be "real-time" depends on how badly the application is affected by unexpected latencies. Regular Java SE might give very low average latency but with occasional outliers (sometimes extreme depending on GC load). Whereas real-time Java might suppress the outliers but is likely to have a much higher average latency. If Java SE doesn't get you where you need then you could at least dowbload an evaluation version of Java RTS and see if it gets you where you need. But you have to determine which you need and whether you are prepared to "pay" for it (both in terms of software licensing costs and development effort).
It also depends on whether you are just concerned about trying to deal with the "node processing" part of the application or whether the networking itself is an issue. TCP/IP is not a real-time protocol. Depending on your OS, using the TCP/IP stack can lead to additional latencies and/or priority inversions (if using real-time). Even on a real-time VM, use of the network stack can lead to non-deterministic response times.
HTH
David Holmes
If you are at the prototyping stage then I would suggest using regular Java SE (Hotspot) and so how far it gets you. You say "the more real-time it is the better" but I think you mean "the faster it is the better". Whether this needs to be "real-time" depends on how badly the application is affected by unexpected latencies. Regular Java SE might give very low average latency but with occasional outliers (sometimes extreme depending on GC load). Whereas real-time Java might suppress the outliers but is likely to have a much higher average latency. If Java SE doesn't get you where you need then you could at least dowbload an evaluation version of Java RTS and see if it gets you where you need. But you have to determine which you need and whether you are prepared to "pay" for it (both in terms of software licensing costs and development effort).