jdev - 2022-10-27

Am I high, or is XMPP over websockets arguably superior to XMPP over plain TCP, because XMPP over websockets has built-in framing?

hm sounds slower, one websocket message can only have one stanza

with tcp i can receive multiple stanzas in one read

you could make that argument, I'd argue XMPP 2.0 should add explicit stanza framing, it's been the source of many bugs, some security issues, and I see no downsides

Is "arguably superior" arguably subjective?

WebSockets also has that weirdo XOR encoding.

lovetox, I mean that's just a different level right? one TCP read can give you multiple websocket messages with multiple stanzas too

WebSocket Messages can also be split into multiple frames, unless XMPP-over-WebSockets forbids that, and things enforce it...

moparisthebest, yes i thought that as well, and it probably must be like that

hmmm

but would be weird or, like say you are a websocket lib and you call send(stanza)

to be clear I'm saying I think framing is good, and that we *could* have it at the TCP/QUIC level, if we wanted it

why would the tcp stack buffer that, and wait for "maybe something more comes i dont send this now"

but i have no knowledge about tcp stuff, so my thinking is most likely wrong

lovetox, most everything ends up writing to a buffered writer that doesn't flush until it's full or flush() is called, including websocket libs

and who calls flush()? the tcp stack itself after some timeout?

im just interested i dont know how this stuff works

i just know, i never called flush() on any buffer ever, this was always abstracted away

hmm I always end up calling flush() :/

I suspect that's a source of bugs if you never call flush. You might be calling other operations that implicitly call flush, but I doubt your TCP stack is doing it for you.

My read of RFC7395 is that frames correspond one to one with stanzas, so no splitting.

Or things are only being flushed once the buffer is full and they might sit there for a while if nobody is sending anything. There may be enough random traffic from various presences and the like that you've just never noticed it, but in theory you could suddenly have nothing sent because you're not caling flush anywhere.

that's correct cmb

also, what Sam said ^

Sam, im pretty sure this is abstracted away

if i use something like GLib, you have no access to any tcp buffers

you have simple methods like write_async()

and it gives you a callback when its done

if the library abstracts it away then it's wasteful in some cases because it has to call flush() on every write

Hmm, yah, looks like Python doesn't let you be explicit about it? I dunno, just doing a quick look at the library

but, it's an ok trade-off

so what do you do? sounds like you also call flush() all the time :D

or whats the other solution? add a milisecond timeout on every write, and wait for more data?

I... call it when I need to

sometimes I send a few stanzas and *then* call flush, sometimes after each stanza

yeah but how to determine that you need to call flush after one stanza?

i mean apart from obvious stuff like stream setup

if I need it sent *now* I call flush

ok and if you dont need to send it now? you wait for something that needs sending now? or you wait a certain time?

wait for something that needs sending now to come along

you could set some type of timer I guess...

ok and is a user written message stanza a category "needs sending now"?

or only stuff like stream header , sasl responses etc

I would say a user written message is "needs sending now"

maybe like a read notification might not be ?

you seem kind of vague, i thought you have written a lib that applies that logic

or is that something which you leave to the application layer to decide

well I haven't written an xmpp client yet :)

ok, so back to websocket

just a lot of networking code over the years

what i like about the standard tcp connection way is, that i dont need dns or any other mechanism to connect to the server

it the worst case its just ip:5222

do we have this for websocket?

kinda, you just grab https://domain/.well-known/host-meta.json and connect to whatever that says

so the xmpp server needs to run a http server

websocket is already an http server

but, yes

websocket is probably also more complicated to setup if you want to serve a normal webpage on 443

well it can be on any domain/port, doesn't *need* to be on the same one

hm thats all that comes to mind for me

on the client side, websocket is much easier

like 1/3 of the code of normal tcp impl

FYI I'll soon write a XEP to expand host-meta.json to support Direct TLS, QUIC, pinned-public-keys, encrypted-client-hello, etc https://github.com/moparisthebest/xmpp-proxy/blob/master/contrib/host-meta/xep-0156-proposed-minimal.json

then you only need to grab that document and skip DNS, POSH etc