Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  About Channels  (Read 3368 times)
0 Members and 1 Guest are viewing this topic.
Offline Jeff

JGO Coder




Got any cats?


« Posted 2007-03-19 14:05:00 »

Actually we use channels in our current App very differently then a typical chat room. I am evaluating the SunGame Server as a replacement for our proprietary server system. And as such I am trying to determine if the API is flexible enough to allow us to use it or not. I can say at this point that the Channel API is very inflexible and geared far to much toward simple chat rooms. What would make this API a bit more flexible would be a slight change in the current implementation.

Change receivedMessage so that it has a boolean return. False would mean terminate propigation while true would mean continue propigation. Additionally, it would be more useful to have the user's channel listener called first and then the application channel listener. This would allow the user listener to terminate the message delivery to the application level if it could be handled at the user level. Or it would allow it to be terminated due to some sort of filter rule for example.

Anyway, we use the channel more like a grouping of users. Not all of which are the same type. And any application would have hundreds of channels each of which might have a hundred or so users of various types. Some DEMO users as an example or observers per-sey. Obviously it would be nice to filter out content sent by observers/demo users before reaching actual participants. The above would enable that.. Of course the client could do that but that breaks the basic security rule that clients can be hacked or bots could be created..

Anyway, I realize that the current API intends clients to send messages to the server/application itself rather than on channels that are consumed/processed by the server. But the api change I am proposing would cost little to nothing on your side while giving developers more flexability in what they could do. My application for example has NO CONCEPT of chatting. And as it stands today the channel would serve little more than a means to broadcast data from the server to the users.

I'd think that the ability to control the content of the messages flying across the channel to one extent or another from the server side would be fairly important.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2007-03-19 14:11:06 »

I think you are laboring under some misapprehension about channels.

The primary purpose of the channel system is to provide as fast-path through the communications layer for clients to chatter amongst themselves.  This is necessary for games that pump a lot of data between clients, such as actions games or even some MMOs for movement.

In order to get this kind of data rate a path is needed through the system that does not involve the logic and persistence   layers for every packet.,  This is why the tutorial tells you to be wary of channel listeners, they actually, to some degree, defeat the purpose of channels to begin with.  If you try to listen to every packet on the stream then you are going to perform no better then if you sent the packet to the server and then it echoed it back to a list of users.

The latter sounds like what you are  looking for and is trivial to implement in the app logic itself.

Note that there *is* a way to get at the channel stream with custom logic without involving the persistence mechanisms and that is to write a custom transport with your own filtering logic embedded therein.

Note that a chat system actually could be easily implemented without the channel mechanism as its throughput needs are much lower.  The channel system is intended as a high-throughput mechanism.

I don't really understand your security issue right now though.  if you don't want a user to be able to talk on a channel, don't joint them to it.  If you need them to be able to listen but nto speak then use two channels, one for "read" and another for "write".

Am I missing something?

JK


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline floersh

Senior Newbie





« Reply #2 - Posted 2007-03-19 18:47:36 »

I think you are laboring under some misapprehension about channels.

The primary purpose of the channel system is to provide as fast-path through the communications layer for clients to chatter amongst themselves.  This is necessary for games that pump a lot of data between clients, such as actions games or even some MMOs for movement.

In order to get this kind of data rate a path is needed through the system that does not involve the logic and persistence   layers for every packet.,  This is why the tutorial tells you to be wary of channel listeners, they actually, to some degree, defeat the purpose of channels to begin with.  If you try to listen to every packet on the stream then you are going to perform no better then if you sent the packet to the server and then it echoed it back to a list of users.

The latter sounds like what you are  looking for and is trivial to implement in the app logic itself.

Note that there *is* a way to get at the channel stream with custom logic without involving the persistence mechanisms and that is to write a custom transport with your own filtering logic embedded therein.

Note that a chat system actually could be easily implemented without the channel mechanism as its throughput needs are much lower.  The channel system is intended as a high-throughput mechanism.

I don't really understand your security issue right now though.  if you don't want a user to be able to talk on a channel, don't joint them to it.  If you need them to be able to listen but nto speak then use two channels, one for "read" and another for "write".

Am I missing something?

JK

1) Our situation is a little different then what you are describing. In our system we DO WANT TO handle almost every single message on the server as the server is what maintains the state and thus the relevantness of every packet. However, the number of groups (what we call channels) of users numbers in the hundreds.

2) We have learned that trusting the client to implement what we expect is a bad idea. Made worse by the fact that the Sun Game Server is open source. There is absolutely nothing preventing people from writing their own clients to it. All they need is a userid/password to the server and they could then do almost anything they wanted.

3) All though SSL over the transport offers a certain level of obscurity for message transmittion I have found that one can easily decompile a program and reverse engineer its data delivery/processing mechanism and the only safe code is that which runs on the server.

4) Our transactions (and they are mostly transactions) result in or involve the transfer of fairly significant amounts of money measured in the thousands for a transaction millions every hour. Security is absolutely necessary.. And real security.. Not security through obscurity.

As for what one intends channels to be, shouldn't one let the developer of the particular application determine what is an isn't the best solution for their environment/program? For those applications that actually do have high transaction volume on the channels and don't have a need to monitor them then don't put listeners on them. But for those that do need/want the listeners doesn't it make sense that they are useful? I mean the listener API as it stands today will take the hit if they use them one way or the other. Why not make them useful if they are going to take the hit anyway?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2007-03-19 19:08:33 »

1) Our situation is a little different then what you are describing. In our system we DO WANT TO handle almost every single message on the server as the server is what maintains the state and thus the relevantness of every packet. However, the number of groups (what we call channels) of users numbers in the hundreds.

Number of groups isn't terribly relevant I dont think.

But my suggestion is that you build this system using client/server communication and Managed Objects.  By your description I think thats really what you want.

Quote
As for what one intends channels to be, shouldn't one let the developer of the particular application determine what is an isn't the best solution for their environment/program?

Sure.  But then don't tell me the solution you picked doesn't fit.  It was your choice.  I'm just giving you advice  on what I believe the best fit is.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #4 - Posted 2007-03-19 19:10:44 »

I think the term channel is confusing the issue a little here.

Channels in SGS are more like virtual TCP multicast things, they are almost transport layer. If you want the server to do some processing before anything hits other clients, then think of the old techniques, you send a message to the server (out of channel) with some identifiers, and it then forwards it on based on security, destiantion etc etc.

I'm sure Jeff will correct me if I'm talking rubbish, but I think your logical devisions are an application rather than transport issue, and should be handled by the application not the transport layer.

HTH

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2007-03-19 19:15:16 »

Yup.  You can think of a channel as a "virtual LAN".

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline floersh

Senior Newbie





« Reply #6 - Posted 2007-03-19 19:54:22 »

Yup.  You can think of a channel as a "virtual LAN".

I realize what they are currently intended for. What i am asking is why not make them more?

It is currently a high speed broadcast mechanism. It COULD also be addressing scheme.

Now I am not privy to the actual clustered code (there may be something there that makes it impossible) but from what I can tell of the current public code it would be trivial to make it robust enough to handle either usage. (Obviously ones application and its needs would drive which way it was used) Aka if your application needs high speed don't use ChannelListeners. If you don't and you would rather use channels for addressing then do use ChannelListeners..

The reason I brought it up is that if ALL applications should use Channels only in the way you describe then why have server side ChannelListeners in the first place? I imagine it was due to some need. What was the need? And what are they good for if not to update the state of the server or to allow the server to mutate the message in transit?
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2007-03-19 20:09:03 »

Well, they are there because of a vague notion that the server might want to listen to certain traffic on a channel.  That would be a low throughput channel.

You do raise an interesting point though... which is whether channel listeners are really useful or just confusing.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #8 - Posted 2007-03-19 20:18:45 »

I think they are useful, it just needs to be noted that listening on a channel will have serious performance implications if it's a large throughput chanel and that you should carefully consider if what you are doing is the right approach.

There is also the question of whether the server throwing a non-retryable exception whilst processing a message on a channel should effectivly vito that whole message, for all clients, or if it's purly a server processing error, and not an indication to trash the message. It doesn't fit with the virtual lan analogy if a server can vito a packet, but analogies are not always a perfect description Smiley, can you clarify what the desired behaviour was and if this is indeed a bug, or an oversite, or intended behaviour.

Cheers

Endolf

Offline floersh

Senior Newbie





« Reply #9 - Posted 2007-03-19 20:47:21 »

I think they are useful, it just needs to be noted that listening on a channel will have serious performance implications if it's a large throughput chanel and that you should carefully consider if what you are doing is the right approach.

There is also the question of whether the server throwing a non-retryable exception whilst processing a message on a channel should effectivly vito that whole message, for all clients, or if it's purly a server processing error, and not an indication to trash the message. It doesn't fit with the virtual lan analogy if a server can vito a packet, but analogies are not always a perfect description Smiley, can you clarify what the desired behaviour was and if this is indeed a bug, or an oversite, or intended behaviour.

Cheers

Endolf

I think they could be extremely useful. Just because most people want to do X doesn't mean everyone does. Let the game developer decide whether to use ChannelListeners or not. And if they do use them then chances are they are using them for some reason. The ability to veto messages could be hugely beneifitial to some while others would simply always return true or not use ChannelListeners at all..

Can I ask you what you use ChannelListeners for? Your first paragraph suggests you are using them..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #10 - Posted 2007-03-19 22:15:01 »

Personally I am not using them right now, but thats because I don't think I have any communications that are broadcast that the server cares about. All the comms that the server cares about are send directly to it. It then decides if the requested action/message is ok and performs the needed task, maybe broadcasting an event later, but that is just my application. Like you said, just becase it's not what one app does, does not mean that another won't find it useful.

Endolf

Offline karmaGfa

Junior Member




Miaow


« Reply #11 - Posted 2007-03-20 15:47:44 »

You do raise an interesting point though... which is whether channel listeners are really useful or just confusing.

A pool might add some light to this issue.

My personal point of view is that I am not sure if the channel listeners are usefull as they are defined in the API:

Some servers might want to listen the channel only occasionally, and with the current API, I don't see a way to do that; it seems that we have to listen from the moment we join a use on the channel until we remove him from there.

If I personally wanted to listen some channels occasionally using the current implementation of SGS, I would simply use a supervisor-client that connect to the server with some special rights and have the server join me in the targeted channel. That way, we don't have to listen the channel all the time, and if the supervisor-client detect something, he can inform the server about this.

PS: I didn't use SGS yet, I just read the whole documentation, I might be wrong.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline floersh

Senior Newbie





« Reply #12 - Posted 2007-03-20 16:00:22 »

Another case I case see the server wanting to attach to the channels is with pseudo users per-sey. Obviously if you have a bunch of clients communicating moves etc via the channel if you have server side users (aka artificial players) wouldn't they need to be kept in the loop as to where the human players were moving? Or would it be better for the clients to send both to the channel and to the server those moves?
Offline karmaGfa

Junior Member




Miaow


« Reply #13 - Posted 2007-03-20 16:17:06 »

Another case I case see the server wanting to attach to the channels is with pseudo users per-sey. Obviously if you have a bunch of clients communicating moves etc via the channel if you have server side users (aka artificial players) wouldn't they need to be kept in the loop as to where the human players were moving? Or would it be better for the clients to send both to the channel and to the server those moves?

IMHO, in the case you describe, the old client/server schema is as suitable since the server's logic need to do a process on each message sent by each client.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #14 - Posted 2007-03-20 18:05:00 »

If you want to do something special with channels, then maybe when the Manager extensions are made public and the docs are out, we might be able to see a really neat way of doing it there, that doesn't mean a data read in the server for *every* packet on the channel. This might be a really good way of doing AI players for example. If they need to, they can then talk to a transaction in the server and then on to managed objects.

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2007-03-21 00:33:25 »

Interesting notion and yes, extension services have access to all other services and can execute "transactionless" code.  So if you didn't need persistence or atomicity you certainly could write a service to handle those functions.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2007-03-21 01:39:00 »

A note on channels:

I just checked with the team.

Although it IS true with the current release that, if you have a channel listener the propagation of messages to other users waits  on the completion of the listener event, this was unintended and is a bug.

It will *not* be true in future releases.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #17 - Posted 2007-03-21 06:46:09 »

Thanks for sorting that one out Smiley

Endolf

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (21 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (87 views)
2014-09-10 06:39:09

Tekkerue (42 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!