licaon-kter
commented
3 weeks ago Unrelatei, but if you build from source why not use latest 24.02?
Closed cmeng-git closed 3 weeks ago
licaon-kter
commented
3 weeks ago Unrelatei, but if you build from source why not use latest 24.02?
prefiks
commented
3 weeks ago You are probably throttled by traffic shaper, check shaper: and shaper_rules: in your ejabberd.yml config. Our default config in latest version have this (i am only leaving relevant rules here):
shaper:
normal:
rate: 3000
burst_size: 20000
fast: 100000
shaper_rules:
c2s_shaper:
none: admin
normal: allwhich will allow regular user send 3k data per second (but we will also allow sending up to 20k data in a single go from time to time), and admin users can send 100k/s. You need to see how that looks on your server, and see if increase this helps.
cmeng-git
commented
3 weeks ago Thanks for the info. The problem is indeed lied with the 'normal' rate which was set to 1000 in ejabberd.yml. I have changed to the following values:
###. ===============
###' TRAFFIC SHAPERS
shaper:
##
## The "normal" shaper limits traffic speed to 3000 B/s (Default)
##
normal: 50000
##
## The "fast" shaper limits traffic speed to 100KB/s
##
fast: 100000
##
## The "proxyrate" shaper limits traffic speed to 200 KBytes/sec
##
proxyrate: 204800
###. ============
###' SHAPER RULES
shaper_rules:
## For C2S connections, all users except admins use the "normal" shaper
c2s_shaper:
- none: admin
- normal: all
## All S2S connections use the "fast" shaper
s2s_shaper: fast
## proxy shaper settings
proxy65_shaper:
- none: admin
- proxyrate: proxy_usersThis will give ~0.5 Sec in reply turn around time. Setting the 'normal' value to 10000, the delay time increases to 5s.
Before creating a ticket, please consider if this should fit the discussion forum better.
Environment
ejabberd version: 23.01 Erlang version: Erlang/OTP 22 [erts-10.6.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-thread OS: Linux (Debian) Ubuntu 20.04.6 LTS Installed from: source loglevel: 5 / 0
Errors from error.log/crash.log
see below.
Bug description
aTalk release 4.1.0 implements XEP-0264: Jingle Content Thumbnails support for File Transfer protocol in both: a. XEP-0234: Jingle File Transfer b. XEP-0096: SI File Transfer
Upon received of a File Transfer Request with thumbnail element, a Bob data request is sent by the recipient. However it is found that the requester needs to wait ~15s before the bob data is received, if the thumbnail size is set to 128 x 96. This long wait is not practical, as the recipient will likely to click the Accept button before even the thumbnail is received and displayed.
In the earlier investigation of the problem, it was thought that the problem lies within smack library, see: Smack 4.4.8: Request of Bob data from sender has a long wait to receive the replied Bob data
However on further investigation, it seems the problem is with the ejabberd server. Following are the logcat captured while carried out test with swordfish sending a file transfer request to swan.
File Transfer Test Setup: a. Swordfish (file sender) on android Note10+ device b. Swan (file recipient) on android AVD API-34 running on Ubuntu 22.05 c. ejabberd server on host with Ubuntu 20.04; debug log level = 0 public IP: 202.166.54.243:5222 Local IP: 192.168.1.8 d. WireShark app is running on ejabberd host e. Image/jpeg 128x96; thumbnail byteData size: 16787 (jpeg);
// ========= Test #1: thumbnail sent as jpeg =======
Based on the ejabberd pcap info: Note: ejabeerd is debug log level = 0 a. ejabberd received the thumbnail in ~80ms sent by swordfish b. ejabberd turn-around time to relay the thumbnail to swan tooks ~15.2s; however this time may vary at different file send instance, once captured time is only ~7s.
// ======== ejabberd wireshark pcap file ejabberd_debug_0_jpg.zip
// ========= Test #2: thumbnail sent as png ======= When the same image is sent as png file, the thumbnail byteData size: 31786. Although the byte transfer takes ~50ms, ejabberd turn-around time to relay increases to 40s.
ejabberd_debug_0_png.zip
// ========= Test #3: thumbnail sent as png, with ejabberd log level=5 ======= Thumbnail byteData size: 31786
// ===== ejabberd log with debug level=5 ======= The ejabberd log shows the received image bytes is segmented into 6 blocks each with 8Kbyte at ~7s interval; this give rise to 40s delay as observed.
ejabberd_debug_5_png.zip