The Mud Connector

Author Topic: Blocks of Text  (Read 2159 times)

GMiller

  • New to TMC
  • *
  • Posts: 6
    • View Profile
Blocks of Text
« on: June 06, 2018, 11:08 PM »
I realize it probably has very little impact overall, however:

When sending a large block of text or data, say with a simple score command, is it better to go with multiple send messages to the socket or condensing the text and sending it in one go? When using a compression protocol, does it make a difference?

Thanks for the help.


Pymeus

  • New to TMC
  • *
  • Posts: 36
    • View Profile
Re: Blocks of Text
« Reply #1 on: June 07, 2018, 3:30 PM »
At the lowest levels, it's optimal to use a few large write()s rather than a bunch of small ones on pretty much any type of socket or file descriptor.

That said, it's my (unverified) understanding that most TCP stacks try to will fudge in miniscule delays when the socket's buffer isn't full.  This allows the network stack to aggregate multiple rapid write()s to the same socket before anything hits the wire.  If true, it may not matter in practice which strategy is used, except probably in extreme cases like writing 1 byte at a time.

EDIT: It's probably the same with most types of compression.
« Last Edit: June 07, 2018, 3:33 PM by Pymeus »
Adventures Unlimited (est. 1999)
connect: tharel.net 5005
 via flash: FMud
website: www.tharel.net
twitter: Tharel_AU

Ateraan

  • TMC Veteran
  • *****
  • Posts: 745
  • New Worlds Ateraan
    • View Profile
    • New Worlds Ateraan
Re: Blocks of Text
« Reply #2 on: June 10, 2018, 2:48 PM »
I realize it probably has very little impact overall, however:

When sending a large block of text or data, say with a simple score command, is it better to go with multiple send messages to the socket or condensing the text and sending it in one go? When using a compression protocol, does it make a difference?

Thanks for the help.
For the most part it won't make a difference. With modern machines, internet speeds, and limited number of players, you won't really notice anything. Just keep in mind data is moved in binary chunks (eg: 2,4,8,16,32,64,128,256, etc). So packets are sent in these formats. Usually if you are sending a data block you can be safe with a 256 byte chunk at a time for the most speed and economy.
New Worlds Ateraan
www.ateraan.com

Tyche

  • Jr. Member
  • **
  • Posts: 79
    • View Profile
    • TheSourcery
Re: Blocks of Text
« Reply #3 on: June 10, 2018, 6:41 PM »
When sending a large block of text or data, say with a simple score command, is it better to go with multiple send messages to the socket or condensing the text and sending it in one go? When using a compression protocol, does it make a difference?

Just ensure that your send output doesn't exceed the size of your programs write buffer.
Your program doesn't have any control on how many TCP packets it will broken into.

That said, it's my (unverified) understanding that most TCP stacks try to will fudge in miniscule delays when the socket's buffer isn't full.  This allows the network stack to aggregate multiple rapid write()s to the same socket before anything hits the wire.  If true, it may not matter in practice which strategy is used, except probably in extreme cases like writing 1 byte at a time.

Yes it's called the Nagle algorithm.  It can be annoying if you are implementing terminal emulation in character mode.
In that case open the socket with the TCP_NODELAY option which turns it off, and all writes will be sent immediately.
Jesus said to him, "I am the way, and the truth, and the life. No one comes to the Father except through me."

nullscan

  • TMC Member
  • ***
  • Posts: 139
    • View Profile
Re: Blocks of Text
« Reply #4 on: June 13, 2018, 1:12 PM »
When sending a large block of text or data, say with a simple score command, is it better to go with multiple send messages to the socket or condensing the text and sending it in one go? When using a compression protocol, does it make a difference?

The Internetwork Protocols (both v4 and v6) provide only a 16-bit header field to indicate the length of the data payload which follows the IP Header, so in no case whatsoever will you send more than 65536 bytes at a time.  When you choose to queue up less than that, you send less than that, but when you queue up more than that via any to-standards Berkely Sockets implementation you'll send multiple IP Packets at 65536+HeaderLength up to the size of the queued data in bytes.

That Nagle algorithm doesn't work well with TCP, so most Berkeley Sockets implementations will offer some form of TCP_NODELAY to disable it.  I'd suggest that you disable it regardless unless you have a low-priority communications product with an absolute assurance that neither side is using any form of firewall.  When working with Telnet you're absolutely working with TCP.

With any well-built MU client, the clientside is going to buffer everything until it finds a CRLF anyway.  The only exception to this is telnet protocol data starting with an unescaped ICC, which is immediately processed as a Telnet Protocol Command if there's enough data following it.

You have no need to give any thought at all to your program's network I/O buffers if/when you're working with a Berkeley Sockets implementation.  The implementation should take care of that, such as by blocking on any write call until there's available buffer space to perform the requested write.  Programmers use asynchronous/multithreaded/multiprocess models for network I/O, to prevent the whole application from hanging during huge write operations.  If your particular project is based on someone else's codebase and async I/O isn't already part of it, then you can work around the processing lag generated by large write-outs by creating a simple synchronous callback to follow each write operation or else you can just deal with large write-outs causing a moment or two of lag for every connected user.  Just bear in mind that "a large write operation" in 2018 is going to be in the scale of at least 10s of Megabytes.

The only buffers you need to worry about are the ones you declare in your own code, and the only write-sizes you need to worry about are what's readable and navigable by end-users with a scrollbar in their client.
« Last Edit: June 13, 2018, 4:42 PM by nullscan »