UDPLSO(1)

📦 version 3.2.1, in ubuntu jammy

Like, picture the most iconic background task you know? Yeah. That's udplso. She's a "daemon" (yes, in quotes, the manpage said it first) and she has ONE job and she does it beautifully: grab LTP segments off the queue that are headed to a specific remote LTP engine, wrap them up all cute in UDP datagrams, and yeet them to the right UDP port on the right host. 🎀

If you don't say a port? It defaults to 1113. No notes. 💅

✨ SYNOPSIS ✨

udplso {remote_engine_hostname | @}[:remote_port_nbr] [txbps]
remote_engine_nbr

🌸 DESCRIPTION 🌸

okay so real talk: udplso is a background "daemon" task, and what she does is extract LTP segments from the queue of segments bound for the indicated remote LTP engine, encapsulate them in UDP datagrams, and send those datagrams to the indicated UDP port on the indicated host. 🦋 If you don't specify the port number, it defaults to 1113.

Now — UDP congestion? You can control it, bestie. Just set udplso's rate of UDP datagram transmission txbps (that's the transmission rate in bits per second, iykyk) to the value that's actually supported by the underlying network. Don't be out here rawdogging the bandwidth. 😭

Every single "span" of LTP data interchange between the local LTP engine and a neighboring LTP engine needs its own link service output task, like udplso. That's just the vibe. All link service output tasks are spawned automatically by ltpadmin in response to the 's' command that starts operation of the LTP protocol, and they are all terminated by ltpadmin in response to an 'x' (STOP) command. So like, you don't hand-spawn these, the admin does it. Periodt. 👑

💀 EXIT STATUS 💀

  • "0" — udplso terminated normally, for reasons noted in the ion.log file. If this termination was not commanded, go investigate and solve the problem identified in the log file and use ltpadmin to restart udplso. 🫶
  • "1" — udplso terminated abnormally, for reasons noted in the ion.log file. Investigate and solve the problem identified in the log file, then use ltpadmin to restart udplso. 😭

🎀 FILES 🎀

No configuration files are needed. Not one. She's low maintenance, highkey iconic. ✨

🌈 ENVIRONMENT 🌈

No environment variables apply. Nothing. Zero. The environment said "not my problem." 🙈

🔥 DIAGNOSTICS 🔥

These diagnostics may be issued to the ion.log log file:

  • udplso can't initialize LTP. — ltpadmin has not yet initialized LTP protocol operations. bestie she cannot start, the LTP protocol isn't even booted up yet 💀
  • No such engine in database. — remote_engine_nbr is invalid, or the applicable span has not yet been added to the LTP database by ltpadmin.
  • LSO task is already started for this engine. — Redundant initiation of udplso. She's already here. She's already slaying. Stop it. 🙈
  • LSO can't open UDP socket — Operating system error. Check errtext, correct problem, and restart udplso.
  • LSO can't connect UDP socket — Operating system error. Check errtext, correct problem, and restart udplso.
  • Segment is too big for UDP LSO. — Configuration error: segments that are too large for UDP transmission (i.e., larger than 65535 bytes) are being enqueued for udplso. Use ltpadmin to change maximum segment size for this span.
⚠️ ngl that last one is a configuration problem, not a crash-y mystery — fix it with ltpadmin, don't just restart and hope. 🧚

🐛 BUGS 🐛

Report bugs to <ion-bugs@korgano.eecs.ohiou.edu>. They want to hear from you, fr fr. 💜

🫶 SEE ALSO 🫶

ltpadmin(1), ltpmeter(1), udplsi(1), owltsim(1)

and that's the whole page, bestie 💖 this one was shipped as perl v5.24.1, dated 2016-07-07, and honestly? she ate. ✨👑

📦 where this page comes from