Lighten up Bandwidth for us 56k'ers (Wishlist)

Lighten up Bandwidth for us 56k'ers // Wishlist

1  |  

robbie

Sep 5, 2002, 6:23pm
Probably the worst problem I have on a slow connection is when adding,
changing or deleting a huge amount of objects, not only am I sending a
packet for every object change, but the uniserver is sending an "OK" packet
back again. This can amount to a huge amount of bandwidth and can make you
go "waiting for server" for a few seconds, requiring you to restart for
updated contacts list and telegrams if its bas enough.

One much better way of doing it would be to have the Uniserver recieve all
the packets then attempt the changes and if its all sucessful send a "all
OK" packet to tel lthe browser that all the changes were successful and thus
halfing the bandwidth and stopping the browser from going WFS.

This could be applied to other common techniques, it would be easier on the
AW servers then as well as helping out us 56k'ers.

Comments?

-Robbie

strike rapier

Sep 5, 2002, 7:22pm
Indeed, and possably sending data in relative form, such as +800 +0 +800 relative to the first object you built of that kind etc, that would allow less numbers to be sent.

- Mark
[View Quote]

tony m

Sep 5, 2002, 8:39pm
[View Quote] > [...] when adding, changing or deleting a huge amount of objects [...]
> [...] but the uniserver is sending an "OK" packet back again. [...]

Umm, I thought it was the WORLD server that handled object data...

hal9000

Sep 5, 2002, 9:13pm
But what happens when that 1 object has an error in the building? you would
have no clue which one it was.

Not only that but the world server doesn't just say "ok the object is
built", it also gives you information like the object number, which the
browsers and bots need if they want to build or anything with the object
query.

The only thing I can suggest would be to build slower, because the browser
and/or the bot, need the response that the world server sends in order to
properly track what's going on. If they aren't sent right after the action
then you may have no clue which is which, unless they do a full query
afterwards, which would be even slower, and take longer than what it
currently does.

--
Hal9000
worlds: Discover, Planets
http://hal9000.wkya.net


[View Quote]

robbie

Sep 6, 2002, 4:48am
world server, my mistake.

-Robbie

[View Quote]

robbie

Sep 6, 2002, 4:50am
If one object gave an error the world server sends an OK packet but one
slightly different from the one which says they all succeeded and in this
one the OK packet is followed by a packet for each object with a problem.
This would cause the same old bandwidth floods in some cases but would
certainly make it happen much less often.

-Robbie

[View Quote]

hal9000

Sep 6, 2002, 5:36pm
"followed by a packet for each object with a problem"
this is where the problem begins, without the world server sending an
identifying number (or "object number") for each object that you add, when
the world server sends the message at the end that "these 3 objects caused
errors", how would the browser/bot know which objects are the ones that
caused the error.

And like I said before, that without the browser sending the new object
numbers being sent as the objects are built, it would require a full
property query of the area, which would take up more time and bandwidth that
just getting the new objects as they are added. And it might even slow down
the server if there was a way to send just the errored objects, because the
world server would have to keep track of many people, building many
"object-clumps", and associating each one with each person, and keeping them
straight when error-checking.


[View Quote]

john

Sep 6, 2002, 7:32pm
You could send a command like:

DELETE 336613 475645454,-543734544,543545345

with all the object numbers

and aw cud send

DELETE_OK 475645454,-543734544

DELETE_BAD 543545345

336613 of course being the CITNUM (mine to be exact)

[View Quote]

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn