jdev - 2022-03-12

im interested in the size of the tcp read buffer people use

currently is use 8192 bytes

i wonder if this is too high, seems like a lot of stanzas can fit into this

which means on every read i would have to process potentially a lot of UI updates

that sounds like the opposite of a problem

why?

lovetox: you'll probably only hit this limit if you get flooded by some entity, like right after authenticating to the server or when joining a huge MUC

i always get flooded from servers

aggregting actions is much better than doing one thing at a time in the event loop

thats the default if you join mucs

if you have trouble coping with that in the UI, optimize the UI code ;)

maybe you have some O(n²) algorithm hidden in there?

what has the tcp read buffer to do with anything?

isn't that more of a choice whether you process the actions caused by stanzas synchronously or asynchronously?

thats not much of a choice

if you say so

the buffer defines the max amout you can receive with a read()

hence limits the UI operations done afterwards

the situation is, you can pull faster data from the network than you have capacity to process in the UI ✏

lovetox: have you thought about not updating the ui in small increments, and instead perform all changes, then doing a single redraw() when the read buffers are empty?

sounds insanly complicated

like i receive a presence, and then wait an amount X maybe i receive an updated presence, and then draw only the last?

depends on your UI framework and on how you interact with it, I suppose

lovetox: well, some programs will just delay the redraw by .2s, others will only issue the redraw after the read buffer is empty

im not sure what you mean by empty, i call read(8192)

is it a blocking or a non-blocking call?

non blocking

so it will return 0 if you are done, and you can issue a redraw then

but it will not return 0 for like a minute

if you join100 mucs on connect

thats what i mean this is essentially a ddos scenario

well, you could have two threads, one doing the stanza processing, the other doing UI redraws as fast as it can

the server sends me a potential endless stream of data

Ge0rG, so you build up a unbounded queue of UI draw events, because the one thread pulls data in faster then the other thread can process

thats what i say, async does not help here

you need to limit the input

to a level what your computer can process

not stuff it into a queue which you process sometime later, maybe

i had 2 ideas, one i limit the read size, meaning i need more time to pull in the data, meaning the ui has more time to update

the second was to just limit the priority of when i call read(), meaning if there any UI events outstanding, i simply not call read() again

lovetox: if you don't do redraws every 8KB, you won't do redraws every 4KB or 2KB

pulling 4x 2 kb from the network takes more time, then pulling 8kb once

some microseconds, yes

it's already there in your network stack, waiting for you to fetch it

yes nevertheless, its an asnyc call, meaning if i call read(), i will not receive anything (even if its already there) in the mainloop iteration where i issued the call

meaning thats a full iteration where other code can do other things

but actually i wanted to know what other people use

so Ge0rG what do you use?

lovetox: I have a dedicated thread doing data processing

and I send events to the UI to redraw.

so when your UI freezes because it needs to process a lot of events, you pull in just more and more data in the background

no, I always process data on a different thread, not blocking the UI

i really having trouble understanding how that technically works, so you receive 200 stanzas, and then you issue 200 events to the ui thread, but it can only process say 10 events / second, so where do the other 190 events go? into some kind of UI event queue? and while that queue builds up you just pull more data in the other thread?

I think I'm pooling things like all presence from a room

presence was an example, great if you are pooling them, but my question was about the how that would work if you getting spammed by a server

lovetox: it's complicated ;) my backend service is storing data in an SQLite DB, and the content provider notifies the UI then

one problem i often come across is, when i need to export data from a jid to hard disk, and i need to name the file like the jid

is there some save jid to allowed chars for harddrive convert thingy

on linux, you can have anything but / and NUL, so bare JIDs go.

on windows, you are in hell

really anything? because full jids also allow stuff like emoji codepoints

lovetox: depends on the fs of course, but on ext4 everything goes.

you don't need to have valid utf8 or somesuch

hm so i replace / with "-" or something, and look when that breaks

> lovetox wrote: > presence was an example, great if you are pooling them, but my question was about the how that would work if you getting spammed by a server How frequent or realistic a scenario is it that you'd be spammed by a server so fast that the UI could not keep up? (admittedly in weechat I use the same model, but only begrudgingly)

pretty high, because in xmpp you can pretty easily amplify the amount of data you get, i can send 100 join presences, resulting in 100.000 presence stanzas

this all depends of course on how fast your server is, how fast your connection is, how fast your computer is

But surely by that logic, when i applied MR677, my gajim should have become unusable and constantly be playing catchup?

Not sure about what you are talking right now, but that is not the Gajim chat and i was not talking about a issue you had

Huh

Still relevant to me, cause i am technically halfway through rewriting my client to use an unbounded queue instead of direct processing, and best i can tell, even with all my mucs open, there's no real risk of not being able to keep up except at initial connect, so unless the UI redraw takes a very long time, i don't quite follow where the risk is, since the alternative is just freezing anyway

that just does not sound like a sound architecture

introducing an unbounded queue

like instead of ui freezing (one problem) you probably have now much more problems ✏

data loss, memory management problems etc

lovetox: what about joining fewer MUCs in parallel? ;)

also a solution, it falls into the category "reducing input"

in my expierience its very easy to write inefficient UI code

lovetox, re JIDs on the FS: on linux, the problem is not what's allowed, the problem is that a JID may be much longer than what a filename may be on ext4 (255 bytes) or even a full pathname may be on linux (it depends™) ✏

jonas’, i know there are multiple problems all not pretty, i just have no better idea, if i offer the user a export off all conversations, and want to put them in plain text, then one file per conversation makes sense

only way to stay sane is sha256 | base32 on the JID if you need to truly key it on the jid and hope that that's hard enough to collide.

is there a better solution to this?

jonas’, but its plaintext export, people should see the filename and know about what it is

not some sha256 string

alternatively you could truncate the individual JID parts (thankfully, DNS also only allows 255 chars), so you could e.g. localpart[:128] + '@' + domainpart[:100] + '/' + resourcepart[:10] + sha256sum(jid).to_hex()[:5] or so

or you might separate domainpart, localpart, resourcepart into a directory structure, which may also be much more navigatable anyway

hm i like that idea on first look

(that still requires truncating on long local- and resourceparts tho)

im fine with a 99% solution here

thanks, i think i will try that with the folders

uh resource can also contain /

hello, do you have any hints, comments, things to avoid, etc about nickname tab completion? for example: - any interesting algorithm to detect what substring of the input to try to complete? normally I would split the string on spaces, but xmpp nicknames can have spaces in them - how do you select which completion to use first when there are multiple matches? depending on who spoke last in the chat? depending on which tab completion was used previously for the same input? any other things to take into account? - really any feedback on how you did it and what makes oyu happy or unhappy about your current implementation

pulkomandy: splitting on whitespace is generally fine, you'd only end up in conflict if you have multiple users with the same first word

pulkomandy: it makes sense to order tab-completion by last-spoke _and_ last-mentioned

poezio only does last-spoke, and I'm frustrated every time when messaging the same person multiple times back-to-back

not sure if last-mentioned-by-you or -by-anybody though

Someone(tm) should push for a wire format to be used for this.

Converse is already using 372, dunno if that's the one, but something is badly needed

pep.: to attach an occupant reference to a message?

that's quite orthogonal

I think that's pretty much the deal. To me it's the same issue as 0071/0393. Randomly matching stuff in body

And not allowing the sender to express intentions

yes, 372 can do that, I will add it to the message when tab completion is used to complete a nickname

Last spoke is super annoying, if you've ever spent significant time in IRC you'll notice people constantly addressing the wrong person because that person spoke right before tab+enter

moparisthebest: only if you have nothing to say

I always do tab, then type a message, then press enter

also, do you use any fancy data structure / algorithms for this (possibly a trie or something like that), or do you consider that the number of people in a room is low enough that it isn't worth it, and just compare strings one by one to find all the matches?

also, case sensitive or not?

case insensitive. good luck getting that right with unicode and each user's locales.

well I don't care about other user's locale, I can just convert everything to lowercase for comparisons locally

ah yes and there's also the case where someone has a nickname starting with [ or ` or some other silly char and I may want to ignore it for completion (or maybe I don't)

In poezio@ there's a user named ☭ sometimes. Looks like they've changed to another symbol today :) ✏

You don't need tab completion if you have only one char in your name :)

The only real vector I've had problems with is people namibg themselves /command something in group chats, depending on the input that can be an attack vector

Depends, let's say symbols are not often mapped on keyboards, and not everybody is into clicking

And being able to match that the nick has been mentioned is also necessary

It's not a completion if you have nothing to base it on, do you do tab conpletions with an empty buffer?

probably won't have a special case to tab-complete cccp to ☭ , at least at first :p (I think that's how compose keys on Linux allow to use this character?)

nephele, sure

As Ge0rG said above, last-spoke and/or last-mentioned

yes, empty buffer should allow to cycle through all nicknames. Preferrably the ones that are not reachable on the local keyboard first?

and yes, that too

Compose key on linux (on X11) is based on a big list somewhere deep in X11 configs, I rewrote that config for myself once to make bindings that make sense

Someone in another MUC changed their name to start with something that looked like an A but was not, so only people using conversations could address them, no one using tab-complete clients could

. ✏

pep., to be fair that user is usually called "ux" and gets annoyed anytime people mention them