Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Networking & Multiplayer / Re: Exception in message disptach; dropping message on: 2007-04-06 14:19:51

Which line is line 406 of

Also, note that a channel message from the server will have a null SessionId, which will cause arg1.toString() to throw NullPointerException.

(BTW you're better off using a SessionId directly instead of calling toString on it.  A SessionId defines equals() and hashCode(), but there are no guarantees on the uniqueness of the String representation of a SessionId)
2  Game Development / Networking & Multiplayer / Re: Long execution/background tasks on: 2007-04-03 23:04:19
I do have a question about all of the log.* files in the data directory.  Why does this continue to grow in size as I run my application?  I'm not storing any managed objects (except for Tasks).  Running for a few minutes gives me a hundred files each 10 megs.

The database log files are part of the normal operation of Berkeley DB.  When you're not concerned about database recovery, you can typically delete most of them (see below).  In a production environment, there are various rules you need to follow when archiving and cleaning logs in order to ensure that the database can be fully recovered, so you don't want them automatically removed in that case.

See for the gory details.

The short version: periodically run db_archive -d to get the list of inactive log files, and remove them.  Note that the db_archive tool is not included in the SGS distribution.
3  Game Development / Networking & Multiplayer / Re: Managing ManagedObjects on: 2007-03-30 19:20:44
I think there are some events we need to be aware of, such as cluster startup/shutdown.

We considered this as well, but here is the problem: what if you trip on all the power cables in your cluster at once?  What happens at restart in that case?

The good news is that the SGS allows you to add any  functionality you want to your application object.  For example, you can create a special "management" client to poke your objects to tell them about certain events, or (a little slicker) create a service that your application objects can register with as listeners for those events.

The key for the SGS core design is to support a lean, scalable set of primitives that you can extend to do anything you need -- and by all means, design that extra functionality as a utility that anyone can use on top of the SGS! Wink
4  Game Development / Networking & Multiplayer / Re: 64 bit Linux and Java 6? on: 2007-03-30 19:13:50
Unofficially, yes.  Both parts of the db should be 4.5.  See
5  Game Development / Networking & Multiplayer / Re: Streaming? on: 2007-03-30 18:55:01
Maybe something like a streaming manager could be implemented.

Certainly.  There is some significant work being done to the SGS IO layer right now, and one goal is to provide an interface that would allow this sort of service to be written.

That said, you'll probably still want to keep bulk data off your SGS stack, at least for now.  We can handle it eventually, but the priority is on the rocket science: scalable, transactional, persistent game logic and communications.

We can always add a fast path around around the deeper parts of the stack for bulk data, but since excellent streaming solutions already exist, we're unlikely to focus on it.  But feel free to contribute your own streaming service implementation!  Grin
6  Game Development / Networking & Multiplayer / Re: RFE, common type for Channel and ClientChannel on: 2007-03-30 18:04:53
Hi, karmaGfa, I'm one of the developers who worked on that API.  We spoke for awhile at GDC.

The classes "com.sun.sgs.client.ClientChannel" and "" are both a channel that allow to send some messages to another network entity, but they share absolutly no type at all, making the API totally asymetric.

Good point!  The short answer is: this is by design.  Let's take it in pieces:

1. Why do the server-side channels have more funtionality than the client-side channels?

Since this is the core SGS API, we want to include only the necessary functionality.  We (or you!) can always build utilities to implement extra features, like letting clients join or leave channels directly.  But if we put that into the core API, everyone would have to support it: all network wire protocols, and all client API implementations (even C++, Java Micro Edition, Flash, etc.).

The core operations let you send a client-to-server session message requesting a join, and your application logic can parse such a request and join the client to the channel.  So while it makes sense to provide a utility for this, it doesn't need to be in the core, so it isn't.

Note that this decision has a design impact far beyond a couple of convenience methods.  If the SGS API directly allowed clients to join or leave channels, we would also need to provide hooks for policy decisions (are all clients allowed to join any channel?  None?  Some?) and so on.  Each bit of extra functionality can exponentially increase the complexity of the other pieces; we chose simplicity.

The main reason to keep it simple is so that we can make a lean, fast, scalable core.

2. Why don't server-side channels inherit from the client-side channels (or from a common supertype)?

The server and client APIs are separate; we were careful to design them not to share anything.

The client API we provide is a reference implementation (and hopefully a very good one).  But we allow any client that speaks the appropriate wire protocol to interoperate with the SGS server, so we don't want to require Java client API implementations to extend a certain class for their session or channel representation, nor do we want the server to depend on a particular client API implementation detail.

<troll joke>Was it because you had a client team and a server team?</troll joke>

Heh, not so much.  In fact, the same set of individuals (myself included) designed the server-side IO and client-side IO interfaces, so these were all conscious decisions Wink

Feel free to follow up with additional questions, and I'll try to explain in more detail.

For your application, where you want to share objects between the client and server even though they don't inherit from the same base class, you need to provide a common interface and write an adaptor class for the server side and client side to that interface.  This is the approach taken in the MPK20 demo, and when that is open-sourced you can see exactly how that works; it sounds like you're using a similar technique.

Thanks for the question!
Pages: [1]
EgonOlsen (58 views)
2018-06-10 19:43:48

EgonOlsen (40 views)
2018-06-10 19:43:44

EgonOlsen (60 views)
2018-06-10 19:43:20

DesertCoockie (225 views)
2018-05-13 18:23:11

nelsongames (141 views)
2018-04-24 18:15:36

nelsongames (140 views)
2018-04-24 18:14:32

ivj94 (881 views)
2018-03-24 14:47:39

ivj94 (142 views)
2018-03-24 14:46:31

ivj94 (793 views)
2018-03-24 14:43:53

Solater (157 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!