HiSpeedDStream -- My attempt to slim down datastream



HiSpeedDatastream is a complete recode of the entire datastream module. It uses no Think hooks, has no memory leaks, and does what it’s supposed to do faster and with less lag that datastream. Of course, at the current stage, the module only has Server->Client streaming. Hooking is easy, transfer is easy, and is all around simpler than the datastream module.

Put in your gamemode folder and AddCSLuaFile it and include it on both client and server.

– Server –

DStream.NewStream(ply:Player,string:HandleID,var:Contents) – Makes a new stream. Returns DStreamObject

DStream.SendStream(DStreamObject) – Begins sending the stream

– Client –

DStream.HookCanReceive(HandleID,UniqueID,Function) – Called when a stream is incomming.
– Return true to accept, false to deny.
– HandleID is the ID of the incomming stream.
– UniqueID is just like a hook.Add unique id.
– Function is your callback function.
– Callback function has one argument (number:SizeOfStream).
– SizeOfStream is the size of the incomming stream in bytes.

DStream.HookStream(HandleID,UniqueID,Function) – Called when a stream has completed sending
– See above for usage
– Callback function has one argument (var:Contents)
– Contents is the decoded contents of the stream.

– Example –

– Server –
local MyStream = DStream.NewStream(Entity(1),“MyTestSend”,{“MyContentsHere”})
– Client –
DStream.HookCanReceive(“MyTestSend”,“HookMyTestSend”,function (SizeOfStream) Msg("Size of incoming stream: " … SizeOfStream … "
"); return true; end)
DStream.HookStream(“MyTestSend”,“HookMyTestSend”,function (Contents) PrintTable(Contents); end)



You have one function more, how is this simpler?
datastream.StreamToClients(clients, uniqueid, table)
DStreamObject = DStream.NewStream(clients, uniqueid, table)

client-side part also only requires a datastream.Hook call. the “accept” thing is server-side.
with clients usually being under total server control, it doesn’t make much sense to allow them to block streams anyway.

also, library names are lowercase :slight_smile:

rated you optimistic cause you expect this not to be flamed by the usual people :slight_smile:

It is simpler in the backend only. The backend of datastream, the crap that makes it (sort of) work, is just all around badly optimized and has alot of unnecessary loops and crap. I pretty much took the idea of datastream and optimized it. HiSpeedDStream also has alot more room to improve from here, as it uses the shared DStreamObject class to hold data, etc.

EDIT: The whole stream blocking thing is more of a convenience function. It just takes the info from the DS_IncommingInfoPacket umsg used to prepare for a stream and redirects it to the client. The real hook is the HookStream function.

edited my first post after you read it…

I’d like to add that I like your client-side hook. no 4 arguments of which you only ever need one anyway :slight_smile:
Will take a look at the code tomorrow


Can you provide some sort of benchmark comparing it to Datastream to further prove your point? :slight_smile:

Also please remove that code tag…

yeah remove that code tag ^^
add [lua] around the code, but not around the description.


in the end, once the backend is running fine and all, you should maybe make an alternative interface or a wrapper so it can be used as a drop-in replacement for datastream.

But then you would run into problems with conflicting datastream modules :stuck_out_tongue:

the idea is to send it to garry to replace the current one :slight_smile:

Been thinking about taking it to that level. But the amount of legacy code to make it all work, I’m not too sure.

I’d write such a wrapper if you don’t want to :slight_smile:

Please tell me that this caches the messages. Please.

I thought about it. Then I thought “Now why would we have more than one message with the same info sent?” It would just take up memory, and be all around a pain in the neck.


EDIT: Will think about it in a later update.

store every single message sent/received and look up every message in that cache? he said it’s going to be less laggy, not more. excessive server cpu usage causes more lag than a few bytes extra transferred.

EDIT: and memory, yeah

if you want to send the same thing over and over again, you use a umsg

Naw, I’m not doing cache.

looks like the Lua Scripting Shitlord Cabal has a new recruit.

I never said it was the cure to any disease or anything. It’s my simple alternative to a not-so-big problem. You may do what you want, but keep comments that do not progress the thread to yourself, please.


Average of 20 benchmarks of HiSpeed DStream: ~62.5ms per stream
Average of 20 benchmarks of the same data with datastream: ~322ms per stream


Would reply but you got banned.

Legend! I am gonna use this.