search

jsxc / jsxc

:speech_balloon: Real-time xmpp chat application with video calls, file transfer and encrypted communication.
https://www.jsxc.org
MIT License
718 stars 241 forks source link

[Discussion] How to implement presence #269

Closed LEDfan closed 8 years ago

LEDfan commented 8 years ago

In this issue I would like to discuss several things about the presence implementation.

XMPP

So if I understand correctly precense in XMPP works this way:

<body xmlns='http://jabber.org/protocol/httpbind'><presence xmlns='jabber:client' from='user@host' to='user@host' type='unavailable'/></body>
<body rid='' xmlns='http://jabber.org/protocol/httpbind' sid=''><presence xmlns='jabber:client'><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jsxc.org/' ver='u2kAg/CbVmVZhsu+lZrkuLLdO+0='/><show>chat</show></presence></body>
<body xmlns='http://jabber.org/protocol/httpbind' ><presence xmlns='jabber:client'><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='' ver='u2kAg/CbVmVZhsu+lZrkuLLdO+0='/></presence></body>
<body rid='' xmlns='http://jabber.org/protocol/httpbind' sid=''><presence xmlns='jabber:client'><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jsxc.org/' ver='u2kAg/CbVmVZhsu+lZrkuLLdO+0='/><show>dnd</show></presence></body>

@sualko is my understanding of the XMPP presence correct?

DanScharon commented 8 years ago

@sualko is it possible for a user to login at one server multiple times simultaneous? If I try with ownCloud, the last logged in session is master and the other connections are logged out.

that is part of the XMPP Core definition and is handled via the 'resource': https://xmpp.org/rfcs/rfc6120.html#bind

We would need a place to store someone's presence. A database is always available so we should start with that

please no. Things like that are handled via PubSub (XEP-0060) and PEP (XEP-0163 and XEP-0207). Please have a careful look especially into XEP-207. This means that you don't need an additional persistence layer as this data is stored on the XMPP-Server.

LEDfan commented 8 years ago

Thanks for your reaction.

that is part of the XMPP Core definition and is handled via the 'resource': https://xmpp.org/rfcs/rfc6120.html#bind

Of course, I forgot about the resource.... But in our situation there would be only one resource at the moment. (ownCloud itself) So not a problem for now.

please no.

I understand that it isn't ideally. But we are implementing a very simple XMPP (actually sort of combination with BOSH since it only supports HTTP) server in PHP. So we can use the JSXC client and not have to worry about client side technology (in the browser). This means we have no running server or daemon. Only direct PHP requests. The goal of this is to have an instant working chat solution. If a large installation wants a good chatting server it will install something like ejabberd.

We also need a database table for broadcasting messages etc. (not ideally again)

sualko commented 8 years ago

you have 6 statuses which the user can choose...

Correct.

when you start a chat session (i.e. opening ownCloud) the XMPP server (owncloud) sends the presence of all users with the following stanza:

Nope. The server sends the presence only after you send your initial presence to the server. http://xmpp.org/rfcs/rfc6121.html#presence-initial

a user can change it's current state via the UI, the client sends it's state to the server via:

In general yes, but there is an exceptions: Unavailable presence is indicated through the type attribute. Please not that you should forward all child elements (e.g. the c element is optional).

when a user logs in, the client sends it current state via:

jup

only the client keeps track of a user current state

yes

there is a subscription model where the user can choose which of the user's presence he wants to keep track

yes

is it possible for a user to login at one server multiple times simultaneous?

yes, but only in two different browsers.

I would assume/hard code that all users are subscribed to each other.

agree

We would need a place to store someone's presence. A database is always available so we should start with that. Basically we only need to store a field user and a field presence.

Agree. You should add a last_active field, because most users do not use the logout button ;-).

like with the locking mechanism we could use Memcache for this too.

You are the expert ;-).

please no.

I think you got this point wrong.

LEDfan commented 8 years ago

@sualko for the last_active field, this should be updated every time the user connects to the server, right? After how many seconds should the user set the state of a user to offline? In the BOSH XEP I read

If the connection manager has responded to all the requests it has received within a session and the time since its last response is longer than the maximum inactivity period, then it SHOULD assume the client has been disconnected and terminate the session without informing the client. If the client subsequently makes another request, then the connection manager SHOULD respond as if the session does not exist. If the connection manager did not specify a maximum inactivity period in the session creation response, then it SHOULD allow the client to be inactive for as long as it chooses.

But since we assume there is already a BOSH connection (and don't use rid/sid) the client don't provide this.

sualko commented 8 years ago

connection manager did not specify a maximum inactivity period in the session creation response

The server is providing this information. But this just btw.

I think a common value for this timeout is 30 minutes, so after this time your implementation should mark the user as offline and announce it to all users which have a valid subscription for that user (as far as you support subscriptions at the moment) and are online.

LEDfan commented 8 years ago

Okay thanks again!

LEDfan commented 8 years ago

I think a common value for this timeout is 30 minutes,

Isn't this a lot of time? I read in the standard that the client should create a new request as soon as another request closes. Since with every request we update the last_active this would mean that if a users closes his session 30 minutes later he will be marked offline.

nitmir commented 8 years ago

Prosody disconnect inactive bosh session with the following message : "Disconnected: BOSH client silent for over 60 seconds"

nitmir commented 8 years ago

In fact, It seems that the client can choose the delay with the wait attribute of the body tag cf https://xmpp.org/extensions/xep-0124.html section 7.1 1min seems more reasonable to me to detect disconnected client because or network failure or just because they closed their browser.

sualko commented 8 years ago

Now I had some time to read XEP-0124 and I found 3 timeouts:

The wait value is chosen from the client (e.g. Strophe uses 60 sec). Inactivity and maxpause is chosen from the server (e.g. ejabberd uses 30 and 120 sec).

LEDfan commented 8 years ago

So a good time would be to use sleep_time * max_cycles + 5? I.e. if the server sleeps 1 second and does this 10 times the timeout would be 15 seconds.

sualko commented 8 years ago

Just use 30 seconds. I don't know what max_cycles is, but 30 seconds should be good enough.

sualko commented 8 years ago

owncloud/jsxc.chat#19 was merged