high level network apis

Networking & Multiplayer
#21

[quote]…this was the other 50% of the point I was alluding to (i.e. not making clear ;)): because of underlying network problems, you cannot fully virtualize the application, because it HAS to change functions depending on knowledge of what transport it’s going to be using. In the example you describe, it may well have wanted to do that anyway (for gameplay reasons), but you cannot just fire-and-forget; you have to make a decision in advance “what method am I going to call” based upon the transport that’s going to be used.
[/quote]
Even if you do decide to put all your app code everywhere and then pick which parts will be used by which device, this can still be done without obviating the value of a clean network abstraction. In the previous example, I can test the line at startup (ping the server, or whatever) and based on the results, enable or disable certain functionality. If network performance suddenly improves, (maybe you’ve got a WiFi enabled phone?) the same app now runs with more functionality enabled, and your slow-phone only functionality now runs faster.

How is this any different from abstracting away the graphics hardware through a common interface like OpenGL? or further abstracting it away through a high-level graphics API like Java3D? You may still need to check the capabilities of the local platform in order to determine what functionality to enable, but that doesn’t eliminate the value of providing a common programming model and functionality across a wide variety of platforms.

#22

Sorry, I’m not complaining :). Just pointing out that the virtualization is - currently - not as perfect as one might hope from reading your earlier posts. OGL certainly isn’t perfect at abstraction either, but people who use OGL aren’t looking for all that much abstraction from the underlying platform, they’re generally trying to get pretty close to it, so as to make pertinent optimization etc. AFAICS (although I’m a relative newbie for OGL) OGL really only abstracts a small amount of stuff - most of the rest of what it provides is a robust mechanism for querying the actual capabilities available, enabling the developer to select the appropriate code path. The major abstraction going on there is a cross-platform capabilities-checker!

#23

[quote]Sorry, I’m not complaining :). Just pointing out that the virtualization is - currently - not as perfect as one might hope from reading your earlier posts.
[/quote]
It is unfortunate but true that one cannot simply disregard the inherent performance characteristics of the network when designing a networked app, and certainly this is even more true when it comes to games. I certainly never meant to imply that JXTA would eliminate this issue for you. My point was merely that JXTA provides a common programming model for network communication regardless of the underlying network infrastructure, and a clean separation of application code from network code. This enables you to choose the transport that best suits (ie is mostly highly optimized for) the network your application is running on, without necessarily having to modify your application to do it.

#24

While very true - the cost to the consumer adds up rather quickly.

#25

[quote]While very true - the cost to the consumer adds up rather quickly.
[/quote]
???
(I’m not saying you’re wrong, I’m just not sure I understand exactly which cost you’re refering to)

EDIT: If you’re refering to the start up costs to the “mobile” consumer there are solutions for this as well. For quite a few apps, discovery doesn’t come into play, so this can simply be excluded from your client. The rest of the configuration protocols are pretty lightweight, and there’s even a version of JXTA (JXME) for extremely constrained devices (~50kb capacity) which uses a remote proxy for discovery and configuration, so that the only thing travelling between the mobile device and other peers at run-time are your (presumably binary) messages.

#26

I’m talking about the dollar cost to transmit data for the user. As of yet, transmitting actual data over wireless networks isn’t free for the end-user - something that currently cripples a good multiplayer game solution for wireless networks. With users paying per kb they receive, sending XML cuts into the bottom line for the customer pretty deeply.

IOW, REAL costs $$$ :smiley:

#27

[quote]I’m talking about the dollar cost to transmit data for the user. As of yet, transmitting actual data over wireless networks isn’t free for the end-user - something that currently cripples a good multiplayer game solution for wireless networks. With users paying per kb they receive, sending XML cuts into the bottom line for the customer pretty deeply.
IOW, REAL costs $$$ :smiley:
[/quote]
Got it. That’s where JXME (JXTA for J2ME) comes in. If you use BinaryDocuments there’s no XML on the phone. All the XML-oriented stuff (Discovery, etc) happens elsewhere.

EDIT: That doesn’t help you with your other point, though, which is that any data, XML or otherwise, is going to cost you, so high-frequency update games are at a significant disadvantage, whether you use JXTA or not.

#28

I should probably take a look at JXME for my next project. I know that JINI does a delegate model as well to remove much of the work from the phone.

#29

[quote]I should probably take a look at JXME for my next project. I know that JINI does a delegate model as well to remove much of the work from the phone.
[/quote]
IIRC, the delegate model for JXME is similar to that of Jini. While I’m a big fan of Jini for certain things, I tend to think of it as a bit of overkill for apps where dynamic discovery of network-aware services is not a priority. JXTA (and JXME) have the advantage of enabling you to use them strictly as a network virtualization layer without having to adapt your programming model to fit it.