I’m not too knowledgeable about threads.
But could you tell me how your thread implementation in the “Spawn” Module.
Is better, cleaner, easier, or more efficient than just using task.spawn() and passing in the callback?
I know you use task.spawn in the return function, but why the extra while true, and the courornite?
Curious.
Can you confirm if this module uses only uses two remotes for server to client and client to server communication? If so, why did you opt for that route? Wouldn’t it have been more performant and a better practice to create remotes individually for each constructor?
we use 3 differents remote to handles both side (server & client), its Reliable, Unreliable & Request.
Each/every remote they have own ~9 overhead bytes specially firing blank and on reliable event they are ordered so to solving this we re-packed it and wrap it every frames without losing the performance instead doing fires/sends every fire function called.
1 Like
Appreciate the response! Curious to know if you ever benchmarked a system where the events are created on the constructor event. All of the bench results in the post (BridgeNet + Red) also use the 3-remote system.
I feel it’d prevent throttling issues down the line (and if there’s a max requests per remote event limit). I know you implemented your own Rate Limiter and Queue system which is awesome, but would it be even more optimized with individual remote objects? Or do you also bunch up requests?
Hey! I’m curious about the recent change in the network module’s batching method. Could you elaborate on the motivations behind switching from grouping all identifiers and data into a table to sending them separately?
I noticed that older fastnet2 versions used the former approach, and I’m wondering what prompted the shift. I’m also interested in understanding the implications of this change, given the overhead associated with firing individual events (around 9 bytes, depending on the environment).
2 Likes
indeed, you cant send a instance to server from client.
its not that its the name of the variable i use, its connected to send over the text of a textbox
Hey, I wanna ask, for remote function kinda event, use :Connect to? Thank you!
Are requests packaged in this module?
can warp send a thing from a server script to another server script because when i try send one message from a server script to another it doesnt print out so did u even test client to client, client to server (which didnt work) and server to server before releasing this to the public?
i did some benchmarking and:
- they’re identical in perfomance (bridgenet2)
- they’re identical in speed (bridgenet2)
- warp doesn’t allow some features that bridgenet2 had
- warp hasn’t got any kind of security whatsoever
u can use a custom signal module or bindableEvent for that.
Can I see the result? I’m curious.
as you know every networking modules dont secure their events data since its not possible but its possible to make the events data format being harder to logging (or debugging) or extract the data manually by exploiter/user and also can by doing validation on receive incoming packets (this still possible can be bypassed).
ok ill try it also what’s in the next update, also i suggest u do caching n the module so it reuses and improves performance like local run = courtine.run but dont add the () onto it. thats how i got a extra 6 fps out of my render with caching.
i think its just yours.
igronecharaaaabbbcccdddeee
Edit: i tested here and no issues like you had
just curious and i just did some benchmark here with impressive results.
pcall have more massive performance over task.spawn (upto 18x faster) here, very weird right where task.spawn supposed to be faster. i might implement pcall and replace task.spawn if there no other issues with using pcall
1 Like
But pcall and task.spawn aren’t equivalent
task.spawn(function()
task.wait(1)
print("B")
end)
print("A")
-- A
-- (one second)
-- B
pcall(function()
task.wait(1)
print("B")
end)
print("A")
-- (one second)
-- B
-- A
4 Likes
Found a bug!
If you do this on the client:
Warp.Client(remoteName):Connect(func)
Without the identifier remoteName being created on the server, this function never runs due to the Serdes module repeatedly waiting. This also yields the entire script, which I’m sure is unintentional behavior.
indeed it requires to create it on server first to receive rate limit configuration. so its not a bug