Expand my Community achievements bar.

Enhance your AEM Assets & Boost Your Development: [AEM Gems | June 19, 2024] Improving the Developer Experience with New APIs and Events

Stratus Like Service

Avatar

Level 1

Hi,

Are you going to make a stratus like service.

No Rooms. P2P only. No fallback. Just connect get the id and do whatever.

Just pay for user minutes. Server Api to give users access to the account,check time spent,limit time.

?

9 Replies

Avatar

Level 1

could a staff member please comment on this?

for some projects rooms are not needed at all.

Avatar

Former Community Member

Hi guys,

Nope, we're LCCS, not Stratus. FWIW, a room is really just a concept, very

similar to exchanging peer IDs - you need some way of having clients

rendez-vous, and LCCS chooses room URLs as a (virtual) location for that

rendez-vous.

nigel

Avatar

Level 1

well, thanks. i'm going for FMS4.

Avatar

Former Community Member

Hi Tom,

Well, that was abrupt... When you say "rooms aren't needed at all", and I say "well, a room is really just virtual, and corresponds to pairs of users exchanging peerIDs", it sounds as though we're talking about nearly the same thing. What's the problem?

FWIW, we use FMS ourselves, so you're not going to get anything much different out of it - you'll be building room instances there too.

  hope that helps - we do care about your feedback, so keep it coming.

  nigel

Avatar

Level 1

nigel, i truly understand the concepts behind LCCS.

for large scale deployments 5000 users in a room are not enough. i'm aware of the fact that this limit is going to be removed in an upcoming version of LCCS, but for now we'd need to open up a room for each pair of users using the HTTP API to be able to scale properly.

all we need is private audio/video chat - having to stick with the "room concept" makes things more complex.

therefore, FMS 4 allows us to have lightweight code and reduce overall complexity. it required less time to setup FMS 4 and get peers to rendezvous than getting started with LCCS to achieve a similar result.

regards,

tom

Avatar

Former Community Member

Hi Tom,

As you say, you'd need to create a room per pair... But is this really that

hard? I'm in the process of writing a lobby system which does essentially

this, and the step you describe is 3 lines of Java code (accountManager

login, accountManager.createRoom, return the room details to the clients).

I'm glad you had success with FMS4, and I'd love to continue the discussion

of how it was easier - are you planning on having 5000+ users connect to one

room instance in FMS, and having them message to each other to exchange IDs?

If so, do you worry that you'll run into scalability problems with this

approach? Again, under the hood we're using the same tech, so we're pretty

aware of where the bottlenecks are (in our case, splitting into separate

rooms means we can spread the load across a cluster of FMS boxes).

Anyhow, let us know if you can share any more of the comparison between

approaches - we're always open to feedback.

thanks

nigel

Avatar

Level 1

nigel, it might be easy, but personally i prefer to avoid any, well, unneeded clutter.

of course, the concept of rooms is well suited for many applications, but not all.

i agree, exchanging IDs with all room members wouldn't scale. therefore we are exchanging the IDs by a utilizing an existing cloud of XMPP backends.

in our case, another benefit of using FMS4 is a much lower latency in comparison to LCCS. with LCCS, it takes around four seconds to be ready to exchange IDs. in my current test with FMS4 (running in a slowmo vm) it takes less than a second.

unfortunately, LCCS won't be available on a european location anytime soon.

Avatar

Former Community Member

Hi Tom,

Fair enough, even if I'm having a hard time parsing the need for a cloud of

XMPP servers as less "clutter" than 3 lines of Java. But we all see the

world differently =). A warning though: ultimately, having all your clients

connect to one room, even just for the purpose of establishing an RTMFP

connection, will eventually start to bog down your FMS box, depending on

your use-case and scale. It sounds like you know what you're doing, but just

so you know why we made the decisions we did to enforce load-balancing.

To the ID exchange, I'm not sure I follow what's happening - are you saying

a message in LCCS is taking 3 seconds to round-trip? Or are you referring to

the time it takes to establish a connection to a room and have the peerIDs

get exchanged (which StreamManager does automatically)? Just want to make

sure there isn't something wrong here.

thanks for the input!

nigel

Avatar

Level 1

i'm just referring to our current project - the XMPP cloud is there already. so in this specific case the "room concept" feels cluttered. again, it is perfectly suitable for different projects.

i'm aware of scalability problems, therefore we are going to apply a "edge-origin" deployment strategy. luckily, FMS4 supports this in terms of RTMFP.

it takes about four seconds for the initial connection to succeed, measured from ConnectSession.connect() to SessionEvent.SYNCHRONIZATION_CHANGE.