[ARCHIVED] Warp - very fast & powerful networking library

Resources Community Resources
, , , ,
#163

1.0.7

  • use --!optimize 2
  • replaced string.pack to buffer instead
  • updated graph benchmark

note: pushing update to github seems not updated correctly, i suggest use .rbxm file instead

#164

1.0.8 (pre-release)

#165

Hello, thanks for sharing with this networking library, I really liked the API and how simple to use it but unfortunately I faced into a problem when ping for our players was constant 1000ms+. When I removed Warp and replaced with default remotes it came back to normal (No network request spamming was in our scripts). Any idea why it happened? Ratelimits was set and we only used Warp in our clan system (other systems was not updated to Warp and still utilize default Remote instances) where network requests is not being used often. Our 2/3 were affected to this weird network latency (3rd game has not used Warp). Version that was used is 1.0.6.
Maybe if I share our client/server code with you in PMs will help you a lot, just inform me.

PS: Also it was fine in testing, problem only appeared after Warp was under use of 100+ players experience

#166

interesting, could you sent your code in pm? also could u do scriptprofiler? did u use :Fires function on server?

1 Like
#167

Not sure what I should do with scriptprofiler. I haven’t used Fires, primary used Invoke() function but I suppose it may be caused by the long timeout that I pass into arguments (10 seconds usually), can’t blame datastore that was used in system since our game spend this budget wisely. Sent you a file in PMs!

Sadly, but I can’t reproduce this problem (We removed Warp from games at the moment) since it only appear on server with a bunch of players :frowning: (I can’t risk our players)

#168

you can use script profiler to know what script that on heavy or the most load (%) on server and client, warp in PostSimulation category.

#169

1.0.8

(1.0.8 - release updates not available on wally package but there version 1.0.8 on wally, its 1.0.8 pre-release not release version.)

Info

Warp are efficiently runs on over or higher 100 players, but Invokes seems not optimized for large-scale, this is unknown to be optimized to runs efficiently on large-scale.

#170

The ids broke for me when moving from 1.0.7 to 1.0.8, I got it back to work by adding:

self.point += 1

In line 74 of the Dedicated buffer module:

function DedicatedBuffer.wu8(self: any, val: number)
	DedicatedBuffer.alloc(self, 1)
	writeu8(self.buffer, self.point, val)
	self.point += 1 --// Added this back from 1.0.7
end

For details, what was happening for me is that all events had an empty string as id which caused all of them to fire whenever I tried to fire a single one.

I honestly do not know much over how buffers work yet, but I will be using it with this temporary fix for now, let me know if there was a deeper reason behind removing that line of code. :sweat_smile:

#171

that seems to be a mistaken when cleaning up.

#172

Yeah

I just added Warp to my codebase and was wondering why it was firing all the events. It looks like i’ll switch to 1.0.7 temporarily until it gets fixed.

#173

If you want to use the 1.0.8 you can also just change the “Dedicated” module inside the “Buffer” module to this: (It’s not an official fix, but it fixed it for me)

--!strict
--!native
--!optimize 2
local DedicatedBuffer = {}
DedicatedBuffer.__index = DedicatedBuffer

local create = buffer.create
local copy = buffer.copy
local writei8 = buffer.writei8
local writei16 = buffer.writei16
local writei32 = buffer.writei32
local writeu8 = buffer.writeu8
local writeu16 = buffer.writeu16
local writeu32 = buffer.writeu32
local writef32 = buffer.writef32
local writef64 = buffer.writef64
local writestring = buffer.writestring

local default = {
	point = 0,
	next = 0,
	size = 128,
	bufferSize = 128,
}

function DedicatedBuffer.copy(self: any, offset: number, b: buffer?, src: buffer?, srcOffset: number?, count: number?)
	if not b then
		copy(create(count or default.size), offset, src or self.buffer, srcOffset, count)
	else
		copy(b, offset, src or self.buffer, srcOffset, count)
	end
end

function DedicatedBuffer.alloc(self: any, byte: number)
	local size: number = self.size
	local b: buffer = self.buffer
	
	while self.point + byte >= size do
		size = math.floor(size * 1.5)
	end

	local newBuffer: buffer = create(size)
	copy(newBuffer, 0, b)

	b = newBuffer

	self.point  = self.next
	self.next += byte
end

function DedicatedBuffer.build(self: any): buffer
	local p: number = self.point
	local build: buffer = create(p)

	copy(build, 0, self.buffer, 0, p)
	return build
end

function DedicatedBuffer.wi8(self: any, val: number)
	DedicatedBuffer.alloc(self, 1)
	writei8(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wi16(self: any, val: number)
	DedicatedBuffer.alloc(self, 2)
	writei16(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wi32(self: any, val: number)
	DedicatedBuffer.alloc(self, 4)
	writei32(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wu8(self: any, val: number)
	DedicatedBuffer.alloc(self, 1)
	writeu8(self.buffer, self.point, val)
	self.point += 1
end

function  DedicatedBuffer.wu16(self: any, val: number)
	DedicatedBuffer.alloc(self, 2)
	writeu16(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wu32(self: any, val: number)
	DedicatedBuffer.alloc(self, 4)
	writeu32(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wf32(self: any, val: number)
	DedicatedBuffer.alloc(self, 4)
	writef32(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wf64(self: any, val: number)
	DedicatedBuffer.alloc(self, 8)
	writef64(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.wstring(self: any, val: string)
	DedicatedBuffer.alloc(self, #val)
	writestring(self.buffer, self.point, val)
	self.point += 1
end

function DedicatedBuffer.flush(self: any)
	self.point = default.point
	self.next = default.next
	self.size = default.size
	self.buffer = create(default.bufferSize)
end

function DedicatedBuffer.new()
	return setmetatable({
		point = default.point,
		next = default.next,
		size = default.size,
		buffer = create(default.bufferSize)
	}, DedicatedBuffer)
end

function DedicatedBuffer.remove(self: any)
	self:flush()
	setmetatable(self, nil)
end

return DedicatedBuffer.new :: typeof(DedicatedBuffer.new)
2 Likes
#174

I do know why you & others ping are so high,

it’s because of warp speeding up everytime a player joins so basically it runs another event of what you send to double the speed which is doubling the ping every time a player joins, and this can cause multiple things to happen like for example if u sent a text containing ‘hello world’ with 1 player in the game it wil send, but with 2 players it would duplicate like this ‘hello worldhelloworld’ or it can get messed up and print ‘hhheeellooworroldd’.

id recommend to use a networking library that doesnt rely on the players for performance.

#175

Like which?

I was initially thinking this is the go-to networking library for low ping and bandwidth because it was better stats than the other libraries. But after experiencing the bug with 1.0.8 literally firing every single remote, it suggests that this library may not be tested, and therefore this library may not be reliable.

1 Like
#176

I’m going to switch to a different networking library until this becomes more reliable.

I first used version 1.0.8, but it is broken. When i called event:Fire(), it fired to every single event, not just the event i wanted it to.

Then, I switched to version 1.0.7, and it had 2 warnings in Script Analysis:
image

The thing is that both of these issues could have been avoided if the creator actually took some time to test the module, and take a look at script analysis before publishing the update.

Reliability is more important than performance.

1 Like
#177

this issue been patched, updated to github & roblox creator.

#178

you can update with new patch to fixes this, and 1.0.7 that u shown is just a type issue where it fixed on 1.0.8.

if you cant found .rbxm file, click here to download directly.

1 Like
#179

I know, but the problems are too frequent. You made a patch in 1.0.7 to introduce another bug in 1.0.8

Please test it yourself before releasing a patch. I want to be able to update my libraries without worrying about whether it will work or not.

3 Likes
#180

I fully agree, this bug was a very clear message to us, users, that this is not being tested thoroughly before release, which is a huge source of distrust.

I like using this library, but I might need to keep it to the side until it gets reliable enough to be used in production efficiently, regardless of player count.

For now I will be using something else while keeping an eye on the progress here. :sweat_smile:

6 Likes
#182

What are you using in the meantime
?
I downgraded to 1.0.6
How did you notice the remote duplication? I haven’t seen any of it as of yet.

#183

It happens when there is more than 1 players in a game like 2 then it would duplicate it.