Hi Guys.

Sun is sponsoring an Open Source track at AGC this year.  We'd like to find non-SUN speakers for the following:

Open Source Tool Chain: In particular the GIMP and open source audio tools if anyone is familiar with that area.  (We think we have Blender covered.)

PyGame (I know your a Java bunch and this is python but I thought it might be worth asking anyway).

Slick

We can't cover trabel expenses I am afraid, but we can get you a speaker badge to the show for your efforts.

If anyone is interested, please email me at jeffrey.kesselman@sun.com

Hmmm...

Slck ES is a pretty cool thing.  I think it will be VERY useful down the p;ike.

Still, it doesn't get us any closer to a JME ES.  Seeing as you've had some experience with both APIs, Kev,
do you think an lwjgl work-alike wrapper around JSR239 is a doable thing or am I totally whacked?

Hey Guys,

I'm not dead, just up to my armpits in Darkstar.

Cas, I tried to make a  login on your forums at lwjgl.com but so far the verification email hasnt arrived.  I sent it to my
gmail account, are you not allowing those?

You will be happy to know that between Slick and JME you have converted me to a happy LWJGL user, though I rarely
get down to that level.  Got a question for youl though.

Google's Android as committed to more or less supporting JSR 239 (they say they may make their own mods) which is
the "JOGL ES" binding.  Id love to get Slick and maybe even JME up and runnin g on an android.  So the question is...
do you think lwjgl could be 'soft ported' to live as a wrapper around JSR239?  What sort of work do you think might be involved?

I have a strong feeling this wont be the last JSR239 ready device we see.  Could this be a way to get an lwjgl based stack that
would run well on all of them?

JK

I'm sorry you took offense.  I tried to hit the high points and focal points.

I didn't mention that JNAG has been ported to Darkstar, and does the object level over Dakrstar channels, either.

We don't feel we force  much of any architecture  on a game, we're hardly a game engine.  We do require you write your server code in an event driven style with fairly short events.  Thats about it that I can think of.  In return, we take mono-threaded code and make it scale out massively across a large scale back-end automatically.  We  load balance, and we fail-over.  We also make the back end logic automatically persistent and gaurantee referential integrity.

In general, I am afraid that such general characterizations as you have given above can devolve quickly  into flame war and  opinion and thats not at all where I wish to go.  Your proud of what you've built.  I'm proud of what we've built. Thats as it should be.

People should take a good look at the technologies and what they offer both in terms of functionality  and in terms of market place.  On our end we are more the just a technology, but a technical initiative.   We are trying to redefine the market for massively mult-iplayer online games in a way that opens it for small developers.  If we are successful, thats another thing to consider.

Once they have done their homework, then they should make an informed decision.  partisan voices will be partisan and thats the sum total of it.

*fine*

Okay so, here's how I see it:

JGN:  Object level communciation.  Lower requirements server side.  Great if all you want is communication

Darkstar:  Byte packet level communication.  More server requirements, a lot more functionality.  Great if you need/want that functionality.
The other thing Darkstar brings you is some industry standardization.  We have big industry players using it now (NCSoft, Gaia Online, etc),  integration with other key game service components like Perpetual's backend,  and are developing a market for hosting providers.  That last can be very important to small developers.

Performance is for the most part a non-issue.  We haven't gone through a tuning phase yet because we are finishing multi-node now but there is no reason why performance doing the same *kinds* of operations (pure channeled message passing) should be markedly different in the long run.
Darkstar *does* push for near linear scalability by adding new nodes to the system.  I honestly don't know what JGN does there.

RMI: A straw man.  It ain't designed for games.  Don't use it for anything where latency is going to be an issue.

For the latest Darkstar information see the sister Darkstar forums at www.projectdarkstar.com

Again I suspect this is all cascade phenomena from the intialize not completeing properly...

My guess is that this has to do with the initialize timing out.

Exactly why that would cause this, Im not sure but Ill run it by our data manager expert.

JK

Very odd.

Ive never heard of HelloWorld throwing a timeout.  It does almost nothing.

Just as a suggestion, make sure the object store is clean and try again.  (you clean the object store by deleleting all the files in the dsdb directory.)

JK

I need more information, when are you getting this error?  What does the rest of the log look like?

Keep in mind that any thread you kick off will be outsiude of the transactional system and unable to read or write data in the object store.

And yes, its really bad manners.  Non transactional code should properly go in services and even then use our kernel to get any threads it needs as we're trying to track resource usage.  Since we haven't told you how to do that yet, though, I realize thats not yet an option.

The static suggestion init  block isnt a bad idea as a work around.  The only problem I  see is that your going to fill system memory with your data where it will remain and this will happen every time you restart the server, not just in the initialize() case.   What you do to create a static code block is this:



This is better then throwing your own thread, but not as clean as using an "admin client" approach.

Sorry, at this time no.


Id say we'll have this resolved in weeks or months.  But beyond that at this time I dont know.

There is one other work around.  Its ugly but it works:  write a special "initialization client" that you connect with after the start of the server to load the data and send it to the server.

This is how wonderland initializes its world currently.
.

Can you split the work up into two or more tasks that chain each other using the TaskManager?

Functionally, channels are primarily for client to client communication. They transfer data from one client to another.

For security reasons this is *implemented* as a star network, which is to say that the data passed through the bottom layer of the back end infrastructure, but (unless you attach a server side listener which is not recommended) it does not involve the logic or persistence layers at all.  It is effectively acting as a router.

[

Nope. getForUpdate() is basically a convenience method.  there is SLIGHLTY more effort  in markForUpdate but its on the order of a lookup.  Nothing that you should see have any effect on your code.

Nope.  No harm in calling it multiple times.




Perfectly reasonable and expected.

You might want to look at the old Linux FAQ for how people successfully built that before we  included it in the SDK.

You clearly have an old release.

Dowload the latest one, it has the Linux binaries/

No, we really do want the feedback.

And we're looking at the options for exceptional tasks that take longer right now-- including making initialize a special case.

Thanks!

No, it means its  limited to the maximum size of your dataabse.  In the SDK this woudl be disc storage where the dsdb is located.


Yes.  For a system that does this, see the Wonderland code base.


Yes this is the current design limit either direction.  Our gut feelign was that  anything that even approaches that size is leaving the realm of interactive communicayion.  If you have a real-world counter example though we'd like to hear about it/


Not realy.  HTTP servers and Streaming servers are built for this kind of massive data distribution.  We chose not to try to replicate that kind of functionality because it already existed and it allowed us to focus on the space the SGS really needed to perform in-- interactive communication.

If you rule out my suggestions to begin with then no, I don't have any other.  I'm not sure how you find an HTTP server complex though...


Thats what Im here for!

JK

Hmm.

Suggestion:  Use one of our startup scripts  (sgs.bat, sgs.sh) get that workign first, then try to write your own.

JK

Dunno sorry, it was a general comment.

This particular solution is not yet implemented... however for practical purposes garbage collection of short lived objects is pretty much a solved problem-- just using other mechanisms.

I suggest you code and not borrow trouble, then analyze, profile and tune.

So, I read the thread.

Im *really* not sure your testing what you think you are.  Even if the code gets inlined from your method there are still questions of whether or not registers get used as efficiently.

Its really not a proper test because you have multiple variables (allocation and method call) and youa re just assuming that all the resulting imapct is from one of them

To test properly you would need to eliminate the other variants.  In this case, it means writing an "add" mthod that uses pooled objects rather then a new.

For:each loops are purely syntactic sugar. They are translated to the appropriate code by the compiler, so
there is no functional difference between a foreach loop and its equivalent explicit construct.

eg.

if
int[] a;

then


Is exactly the same as

They probably had a download limit or something

Your basically correct.

Your task code is called  by the system.  Commit happens after your code returns control to the system.

Thus although serialization happens in the same thread as your code, it happens  outside of  your code itself. 

A full trace would just show the call stack disappearing into the bowels of our tasking kernel.

1.5 would be a Java version, not a Darkstar version.

if you don't have at least Java 1.5_11 under IWn32 then yes you need to upgrade.

get that here:

http://java.sun.com/javase/downloads/index.jsp

If you want to dl the 9.2 version of Darkstar get that here:

https://games-darkstar.dev.java.net/license.html

You need to click the accept button at the bottom of the license.  Downla`oad should the start. Depending on your browser, it may or may not tell you downla`oad has started so check your "downloads" window in the browser.

Nope.

Cause that exception isn't thrown when you put it in the field.  We have no way of catchign that.\\

The exception happens in the SGS commit code.
The suggestion that it report the object whose serialization triggered the exception though is a good idea.


Cool.  Im sure everyone would love to see a screan shot or two when your ready!
.

Good thought, I'll suggest it to the team

We're working on the Darkstar ortal now,  One thing we should definitely have is an RFE section to catch these great ideas in a more organized fashion.

TCP and UDP use the same underlying internet transport mechanism.  Under good communication circumstances where you are not getting packet loss and with enough bandwidth to cover what you are transmitting plus your packet overhead, timing by definition MUST be identical.  If you don't believe me, go buy a textbook.

At TEN (Total Entertainment Network) we did solely TCP/IP because its actually lower bandwith over PPP, which was our last critical mile for most of our customers.  (Most customers were dial-up back then.)

We had the best QUAKE2 play on the internet and ran DukeNukem3D and Nascar Online Racing flawlessly for anyone with a decent connection.

Many people do not understand TCP and misuse it.  In these "timing tests" you speak of, did you disable nagle's algorithym?  The problem with a benchmark generally is that, unless you are an expert  on the thing you think your measuring, its likely the results don't mean what you think they do.

UDP becomes *worse* then TCP as soon as you need TCPs gaurantees.  You end up having to reinvent TCP, but in a way that the net does not understand and can't therefor help you optimize.


Heh, well I wasn't going to say that, but I was going to say something equivalent... always ask for the lowest level of guarantees that you need for your app.  In general the lower the guarantees you ask more, the more room the underlying protocol has to optimize things.


Totally depends on how you design your MMO.

Guildwars is 100% TCP/IP and runs fine because it was designed for that.  (If you dont believe me, fire it up and do a netstat.) Often, MMO desigenrs go for a mix where they seperate data that is critical or needs to be ordered from data that doesn't and use seperate communication paths for each.  The gain for the added complexity is not clear, but it makes some developers more comfortable.


No we really havent gotten to the point of stress testing the comm layer in a scientific way.  Among other things, until we finish the production (multi-node) servers there are parts of the equation that shoudl be included that we can't measure.


This is up to the protocol handler, which ultimately means its up to you.

Our default protocol handler does "unordered/unreliable" over UDP and anything with gaurantees over TCP.  However, it would be incorrect for you to start building a client-level reliability scheme ontop of our unordered/unreliable.  Rather, if you want a different mapping such as an actual UDP based "unordered/reliable", you should do it through a custom protocol handler.


My pleasure.

I was at a conference today that was addressed by James Gosling.

According to him Java 6 is regularly *winning* performance shoot offs with C and with Fotran for scientific computing.  And apparently there are still some improvements that the Hotspot team is working on that he believes will pull us even more dramatically out in front..