Warp - very fast & powerful networking library

try send fewer data per second

Ok, also im going to implement the module on the other scripts i use. does the :Invoke method use buffers to covert data since remote functions is the only way to prevent my things from duping so yeah

no, invoke doesnt use.

###############


The provided example on the doc website throws an error.

image
i passed two instances (client image)
image
and the other got swapped for some reason (server image)

is there a reason for this? seems like a waste of possible savings

1.0.14

  • Added .OnSpamSignal Signal
  • Fixed Buffer deserialization to Instances type
  • Fixed a memory leak in ServerProcess.luau (@MuffinHandler)

Ok, if you can, implement the buffers onto the invoke method in the next update and the ratelimit thingy. but otherwise the Invoke method is alot better in terms of performance compared to remotefunction

also the peformance and stability is alot better compared to the last time i used it which is nice

hey does warp support returning in another script thats connected to the same :Invoke event? when i try to return a message like this:

if chat then
    return "done"
end

it wont return back to a localscript even though the variables is correct

Your benchmarks are wrong. It uses remote events but its faster than a remote? Misleading

Updated the Test Benchmark result sample to latest.
Make sure you have read the ā€œImportant Noteā€ first for the benchmark resultā€¦

On the benchmark, warp is still very-fast with the new dynamic buffer serialization

For my opinion for thisā€¦, red2 is good but too complicated and a bit confusing for the APIs and i do not recommended to use BridgeNet2 for very-large game task scale usage, due to the issues & archived resource same as Red2 (no longer being maintained/updated)ā€¦ but its all up-to-youā€¦

Hi! Iā€™m still experiencing issues with sending instances. On Warp v1.0.12, everything works fine, but in Warp v1.0.14, the first time I fire a remote, it doesnā€™t respond. Only on the second attempt does the remote pick up the instance. (I assume thereā€™s an issue with connecting the fired remote)

Yeah because the amount of data that is being passed through the remotes is less than the normal remote data due to buffer implementations.

So itā€™s faster because it has to pass less data so read less data.

No. its because in their benchmarks, they dont measure the overhead of calling RemoteEvent:FireXXX. Its a misleading benchmark. Compressing data into a buffer takes extra time compared to just calling a remote directly

Instances is not supported fully through the buffer implementation, it will return the raw buffer due to a bug. Also if you want to try something really fun, then look into memory leaks that it has right now.

It also appears it tries to make a small string a buffer, which will actually increase how much is sent through the remote. Imagine you have a string you are sending through a remote. That string is ā€œHello from Serverā€. With the current version/implementation it will actually make the sent kb bigger because it gets encoded into a buffer, for no reason, small strings like that should not have been encoded.


1 Like

Warp doesnā€™t support handling when events are being spammed, it will just insert in the queue which will at some point will overload the server which will cause high ping for every client, the solution is that the developer have to kick the player.

Infact, whenever the player who is spamming the event leaves, the queue for that player will not be cleaned up until its processed.

At this point, using default remote events is way better, you can make your own wrapper which will compress the data.

Compression should only take place if the data is large, the fact that passing buffer for ā€œhiā€ string will take more bytes than the actual string itself, warp also sends Identifier string to the client which takes few bytes, so making different instances for remotes is fair.

Swift

Iā€™ve made a wrapper called SWIFT which handles every complex stuff including ratelimits or compressing large data, @MuffinHandler and me we both tested it and its way faster.

Redā€™s dev made a different module called zap

at v1.0.14, there is.

Warp.OnSpamSignal:Connect(function(player: Player)
end)

its not a module or library but its a tool.

i figured out how to return because i saw a post on this forum of a example of returning things. i implemented it and now when i print out the result from the localscript it returns nil. tried everything like using return message == message and sendrequest(url,ischat) and comparing it to the example but it doesnā€™t work. the other function and everything else seems to work fine and everything its just the local script either not receiving it properly or its something in my code. When I tried the example the example works perfectly fine.

heres some pieces of code:

client side

function chatcontroller:sendmessage(chatmsg)
	local result = chathandler:Invoke(0,true,chatmsg)
	print(result)
	if result and result == "Sent message..." then
		controllerui.Text = result
		playerinfo:Fire(true,"chatMSGd")
		chathideevent:FireServer("chathidekeyboard789")
		button.Visible = false
		for countdown = self.timer, 1, -1 do
			task.wait(1)
			self:resetUI(string.format("Please wait %d seconds before sending another chat message", countdown))
		end
		self:resetUI("")
		button.Visible = true
	elseif result == "Failed to send message." then
		controllerui.Text = result
		task.wait(3)
		self:resetUI("")
	end
end

server side

local function handlechatthing(player,ischat,message: string) -- message is where the chat message comes from
	print(message)
	task.wait(1)
	if not message then
		warn("no message")
		return message == message and "error no message received"
	end
	Holder = player
	local url = urlforchat .. HttpService:UrlEncode(tostring(message))
	modinfo:Fire("updchatname", player, message)
	playerinfo:Fire(player)
	return message == message and sendRequest(url, ischat) -- does return a function but when used in regular remotefunctions, the function returns a string of text instead of the entire thing.
end

little piece of how the sendrequest function returns:

if ischat then
		print(ischat)
		return "Sent message..." -- tried returning it with "return arg == "Sent message..." but didn't work.
	end
end
  10:04:50.367  nil  -  Client - chatscript:37
  10:04:50.385  das  -  Server - Chat, GameID, Key Handler:105
  10:04:51.915  true  -  Server - Chat, GameID, Key Handler:100

nil is from the chathandler:Invoke thing.

it could probably be me returning a function that returns a message when triggered who knows

fixed it had to change timeout from 0 to 1. It wont return if the timeout is zero pls fix

you supposed to not put the timeout as 0, it will immediately return as nil.