Size of a string in bytes, for networking...

[ArchAngel075]

So I moved from using Lua-Enet to LuaSocket for my multiplayer games and while writing up debugging utilities to help me I realized that LuaSocket does not have a getMessageSize() function.

So Im asking here if getting the size of the strings sent and received is the same as getting the size of the messages being sent and received?
Ie, if I send "hello" accross the network to a client, is the packet/message size in bandwidth(i think is the right word) the same as doing #"hello" ?

or is there some other method i can use?
I wish to be able to know how much data is being sent and received per packet in order to monitor bloated and bottlenecking packets (for latency reduction when needed)

[bartbes]

Not quite, but it's a constant cost until you go over the limit of a single packet. So generally speaking, the length of the data is indicative of the length of the packet in such a way that you may as well use it as a substitute.

[ArchAngel075]

Thanks, i have already started using it as a substitute or assumption(works pretty well, as a 55kb file produced roughly a 55k packet)

Though ive now come accross a new issue.. When sending packets i noticed that exceeding a packet size of around 8000 the program refuses to send.. as a result i had to write up a really hefty fragmentation utility to fragment large packets that recompile on receive.
But to more specific on how large i should limit each fragment of the whole, what is the known highest amount of data that LuaSocket will send?

[mickeyjm]

According to the LuaSocket site it defaults to 8192 bytes, but you can change that by calling

Code: Select all

udp:receive()

with a size argument, eg

Code: Select all

udp:receive(16384)

[ArchAngel075]

Oh.... well...

Im using Lube as my framework, so if i scrounge the code and find that udp:receive call ill specifically change it and see how life treats me,
much thanks for the pointer there

--EDIT--

THen what IS the absolute limit LuaSocket handles ?, or will i need to do udp:receive(2^32) and pray

[mickeyjm]

Oh, yeah sorry I misread the document the first time, 8192 is the maximum. I misread it as it is the current maximum but you can up it by changing the number. I guess you'll have to either use some kind of workaround like splitting the packets and sending them (but then you have to reorder them at the other end) or try and only use smaller sizes

[bartbes]

I think luasocket places that 8k limit on sending as well, so there's no way around that (that I remember).

[ArchAngel075]

Well like i said, I have made a fragmenter for packets that exceed 8192 (actually 7936, head way of 256)
split the packet into separate 7936 packets with a special Header and UID (based on osClock and os.date-very reliable as a unique id for this case)
The receiver tores all received fragments and compiles when received the last fragment(with a special Footer) - THOUGH :
Currently it assumes that there will be no more fragments after the last(footer-ed) fragment so if it receives it first...breakage

Im currently rewriting my ArchNet utility library to make fragmented packets track missing fragments and request the missing indexes, going to be hefty but if complete i will share as the ArchNet library i use is pretty useful for handling packets cleanly

A friend told me to look at using cmd and winrar or GZIP as a third party fragmenter setup, if it does what i need ill use it and share ArchNet..

If any other options for fragmenting libraries are known please share

[slime]

Why did you drop ENet? It does all that (and much more) automatically.

[ArchAngel075]

Had some issues with it, Though needing to build my own systems for LuaSocket helps me have a more better understanding of where to tackle latency inducing systems in my code and atm rebuilding my CurseEngine for a 5th time to use LuaEnet (if i switched after discovering tricks to reduce latency) would just make me give up haha...perhaps when this rebuild (v4) becomes too messy or I get overly frustrated with LuaSocket aswell...