|
Just to chime in on this briefly. You
can fairly easily build a chat system using FDS without dynamically defined
client and server destinations and it is not too much work though it has some
limitations in how it will scale if you take the simple approach. I think
for Tom’s particular scale requirements, this approach would not be
sufficient but if you are only dealing with a server that has at most a couple
of thousand concurrent users, this may well be the easiest and best approach,
especially if your app requires some back-end integration. Of
course the exact load you could support would vary based on your setup but you’d
be able to expect a reasonably high volume of messages/second hundreds but probably
not multiple thousands. To get extra scale, you have change the messaging
topology we use in today’s FDS (something that we are considering adding “out
of the box” for a future release). Here is the outline of
this approach: -
Basically
each user could create a Consumer with a subtopic to receive chat messages and
presence queries. You could use the IM identity as part of the subtopic
name – e.g. “myIdentity.messages”. The client would also
send messages to a different subtopic also based on the identity for publishing
presence events e.g. myIdentity.presence. When the client connects,
it would also send an initial “I am available” message to the
myIdentity.presence subtopic, then would send additional messages such as “I
am idle” as its presence state changes. On the server side,
you’d have a session destroy listener which would send the final “I
am disconnected” message to this subtopic from server code. If
you are using HTTP sessions, you should probably put a timestamp in each
presence message and the timestamp for this “disconnected” message
should be the current time minus the session expiration time interval (since
that is the time of last request seen by this user when the session expires). Make
sure you do not replace a more recent presence event with an older one in case
this user has logged on via a different browser in the meantime. -
Secondly,
to get visibility for other user’s presence events, the client would make
an RPC call to some server component you provide which supplies the client with
their buddy list. The consumer would then issue Consumer.subscribe calls
for each buddy’s identity’s presence subtopic. Once it
had subscribed to all of these, it would send a “presence query”
message to the myIdentity.messages subtopic. In response to a presence
query, the client just sends a presence event to its myIdentity.presence
subtopic with its current presence state. One other type of message you
receive on the myIdentity.messages subtopic would typically be actual IM’s.
The body or headers of the message can contain things like the thread-id, the
sender etc. You’d also use this channel to send other control
messages such as “an add buddy request” has been received. Of course a real IM system requires
authentication and access control, buddy list approval but I think you can
implement this with these two subtopics per user. One representing data
and control messages intended for the client, the other for data and control
messages sent by the client. For buddy list approval, you
send another control message to the user’s “myIdentity.messages”
subtopic and the buddy would reply with a control message to the other user’s
“theirIdentity.messages” channel. You can extend the
class flex.messaging.services.messaging.adapters.MessageAdapter and override
the allowSubscribe and allowSend methods to add authentication. The scalability is limited in this
approach because with the current FDS “out of the box” messaging
topology, every message goes through all servers in the cluster so it will not
continue to scale as you add servers. It will work in a clustered
environment though and so will provide fault tolerance. It is also possible for you to change the
messaging topology with a custom message adapter though now you would be
getting into some real coding effort. To do this, you must handle
subscriptions yourself by overriding the “handlesSubscriptions” and
then the “manage” method gets called with the subscribe and
unsubscribe messages. I think a more scalable topology for chat would be
to broadcast only the subscribe, unsubscribe, and presence change events, then
to cache the presence state for all users on all servers. This would add
an order of magnitude or two of scalability in an IM system. To get
complete scalability, you partition the users using some kind of a hashing
scheme. Jeff From: Hi Tom, -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___ |
- RE: [flexcoders] Building a chat server over FDS... impossible ... Jeff Vroom
