It appears that if the viewer requests a folder containing links, we must also send the folders that contain the link targets first.
This was tested with Kokua 0.1.0 WIP though I predict it will also work with other viewer 2s
limits because the only ones used now are the defaults (which are overwritten
by the client throttles anyway). Updated the default rates to correspond to
about 350kbps.
Also added a configuration to disable adaptive throttle. The default
is the previous behavior (no adaptation).
command to look at the entity update priority queue. Added a "name" parameter
to show queues, show pqueues and show throttles to look at data for a specific
user.
per Melanie's very good suggestion. The immediate queue is
serviced completely before all others, making it a very good
place to put avatar updates & attachments.
Moved the priority queue out of the LLUDP directory and
into the framework. It is now a fairly general utility.
clients. If the sent packets are ack'ed successfully the throttle
will open quickly up to the maximum specified by the client and/or
the sims client throttle.
This still needs a lot of adjustment to get the rates correct.
Often, by the time the UDPServer realizes that an entity update packet
has not been acknowledged, there is a newer update for the same entity
already queued up or there is a higher priority update that should be
sent first. This patch eliminates 1:1 packet resends for unacked entity
update packets. Insteawd, unacked update packets are decomposed into the
original entity updates and those updates are placed back into the
priority queues based on their new priority but the original update
timestamp. This will generally place them at the head of the line to be
put back on the wire as a new outgoing packet but prevents the resend
queue from filling up with multiple stale updates for the same entity.
This new approach takes advantage of the UDP nature of the Linden protocol
in that the intent of a reliable update packet is that if it goes
unacknowledge, SOMETHING has to happen to get the update to the client.
We are simply making sure that we are resending current object state
rather than stale object state.
Additionally, this patch includes a generalized callback mechanism so
that any caller can specify their own method to call when a packet
expires without being acknowledged. We use this mechanism to requeue
update packets and otherwise use the UDPServer default method of just
putting expired packets in the resend queue.
this appears to cause problems with the system timer resolution.
This caused a problem with tokens going into the root throttle as
bursts leading to some starvation.
Also changed EnqueueOutgoing to always queue a packet if there
are already packets in the queue. Ensures consistent ordering
of packet sends.
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
when client and simulator throttles are set. This algorithm also uses
pre-defined burst rate of 150% of the sustained rate for each of the
throttles.
Removed the "state" queue. The state queue is not a Linden queue and
appeared to be used just to get kill packets sent.
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
when client and simulator throttles are set. This algorithm also uses
pre-defined burst rate of 150% of the sustained rate for each of the
throttles.
Removed the "state" queue. The state queue is not a Linden queue and
appeared to be used just to get kill packets sent.
time to wait to retransmit packets) always maxed out (no retransmissions
for 24 or 48 seconds.
Note that this is going to cause faster (and more) retransmissions. Fix
for dynamic throttling needs to go with this.
Handling these synchronously kills the inbound packet loop if many requests are made for remote land and those requests are handled slowly or timeout (timeout is 10s)
This can happen if a user searches for "land for sale" and then clicks many of the parcels in the list (or just presses down arrow to move through every entry).
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
time to wait to retransmit packets) always maxed out (no retransmissions
for 24 or 48 seconds.
Note that this is going to cause faster (and more) retransmissions. Fix
for dynamic throttling needs to go with this.
In order to pass ILandObject into IClientAPI.SendLandProperties(), had to push ILandObject and IPrimCounts into OpenSim.Framework from OpenSim.Region.Framework.Interfaces, in order to avoid ci
Counts are showing odd behaviour at the moment, this will be addressed shortly.
This is in a very crude state, currently.
The LindenUDPModule was renamed LindenUDPInfoModule and moved to OptionalModules
OptionalModules was given a direct reference to OpenSim.Region.ClientStack.LindenUDP so that it can inspect specific LindenUDP settings without having to generalize those to all client views (some of which may have no concept of the settings involved).
This might be ess messy if OpenSim.Region.ClientStack.LindenUDP were a region module instead, like MXP, IRC and NPC
* Added Calculating Time Dilation in the OdePlubin
* When multiple object updates are stuffed into one packet, average the time dilation between them as a compromise.
* Time Dilation on the update is calculated when the EntityUpdate object is created. The pre-calc-ed TD is stored in the Entity update and used when it goes out on the wire. Previously, it was 1.0 all the time. The time dilation is tied to when the update is created, not when the update is sent.
* Adds an item that checks to see if the top request has been there for longer then 30 seconds without an update and sends an AbortXfer if it encounters one. This allows the client to cancel the Xfer on it's side so you can re-select the prim and get the inventory when it fails the first time.
* Some interesting locking... Using NewFiles to lock the rest of them. We'll see how that goes.
* The goal of this is to ensure that Xfers are restartable when they fail. The client will not do that on it's own.
These locks are necessary to avoid a delete/update race condition for scene objects.
However, since we're now locking on m_killRecord this shouldn't cause delays to m_entityUpdates reprioritization
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
Revert "This may have been the biggest, baddest bug in OpenSim ever... confusion between bytes per second and bytes per millisecond."
This reverts commit 870bbcfc6c.
If an LL 1.23.5 client (and possibly earlier and later) receives an object update after a kill object packet, it leaves the deleted prim in the scene until client relog
This is possible in LLUDPServer if an object update packet is queued but a kill packet sent immediately.
Beyond invasive tracking of kill sending, most expedient solution is to always queue kills, so that they always arrive after updates.
In tests, this doesn't appear to affect performance.
There is probably still an issue present where an update packet might not be acked and then resent after the kill packet.
For each agent, this command shows how many packets have been sent/received and how many bytes remain in each of the send queues (resend, land, texture, etc.)
Sometimes useful for diagnostics
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
Setting this to true avoids a 500ms or so client freeze when the LLUDP server thread is taken up with processing a UseCircuitCode packet synchronously.
Extensive testing on Wright Plaza appeared to show no bad effects and this seems to reduce login lag considerably.
Of course, a lot of login lag is still coming from other sources.
It contains a major interface version bump and will NOT work with earlier grid
services. This is preliminary work that will lead to layers support.
Rest appearance services are commented out completely, they will have to be
adapted by someone who actually uses them. Remote admin is working, but has
no layers support. There is no layers support in the database. Login likely
won't work. You have been warned.
AvatarService -- add two new methods, GetAppearance and SetAppearance
to get around the lossy encoding in AvatarData. Preseve the old
functions to avoid changing the behavior for ROBUST services.
AvatarAppearance -- major refactor, moved the various encoding
methods used by AgentCircuitData, ClientAgentUpdate and
ScenePresence into one location. Changed initialization.
AvatarAttachments -- added a class specifically to handle
attachments in preparation for additional functionality
that will be needed for viewer 2.
AvatarFactory -- removed a number of unused or methods duplicated
in other locations. Moved in all appearance event handling from
ScenePresence. Required a change to IClientAPI that propogated
throughout all the IClientAPI implementations.
Object updates are sent on the task queue. It's possible for an object update to be placed on the client queue before a kill packet comes along.
The kill packet would then be placed on the state queue and possibly get sent before the update
If the update gets sent afterwards then client get undeletable no owner objects until relog
Placing the kills in the task queue should mean that they are received after updates. The kill record prevents subsequent updates getting on the queue
Comments state that updates are sent via the state queue but this isn't true. If this was the case this problem might not exist.
This is necessary because it was still possible for an entity update packet to be constructed, the thread to pause, a kill to be sent on another thread, and then the original thread to resume and send the update
This would result in an update being received after a kill, which results in undeletable ghost objects until the viewer is relogged
Extending the lock looks okay since its only taken by kill, update and reprioritize, and both kill and update do not take further locks
However, evidence suggests that there is still a kill/update race somewhere
* Removed StorageManager
* CONFIG CHANGE: There are no more database settings in OpenSim.ini. Check the config-include configuration files for region store and estate store database settings
These levels correspond to packets that one isn't usually interested in when debugging (e.g. regular outgoing SimStats packets)
This is equivalent to what we had a year ago before it was removed. It's extremely crude since it doesn't allow one to pick individual clients or packets. However, it can still be useful when debugging packet race conditions.
On Linden Lab clients and some derivatives, receiving an entity update after an entity deletion notice results in an undeleteable prim that disappears upon client relog.
This check was dropped in 0.7 for unknown reasons but renewed testing demonstrates that queued updates can still be present after a scene object has been deleted.
At least on stock Linden clients, updating the texture on all faces of the prim will actually send an ObjectImage packet for each update.
There is a race condition if these are handled async, meaning that occasionally not all of the faces are correctly updated.
DisableFacelights option to OpenSim.ini to finally kill those immersion-
breaking, silly vanity lights that destroy nighttime RP. Girls, you look
just fine without them. Guys, you too. Thank you. Melanie has left the building.
nonworking ownership assignment in SOG, which messed things up before.
No longer trust the client to send the ID of the person something is copied
as, since it allows to run a script with someone else's permissions. Properly
adjust inventory ownership and perms.
This is one step towards reducing hud glitches on region crossing, since the viewer fails to display prims if it receives child full updates before the root prim full update
This commit also introduces a mechanism in LLClientView to stop child attachment updates ever going out before the root one
This is a very temporary mechanism and will be commented out when the next step of the fix (to give root prims higher udpate priority) is committed
This code is a foreport from the equivalent changes in 0.6.9-post-fixes
* Simplified the interest management code to make it easier to add new policies. Prioritization and reprioritization share code paths now
* Improved the distance and front back policies to always give your avatar the highest priority
This implements the 'share with group' flag for notecards and scripts in prim inventory since the PermissionsModule checks group membership and permissions.
Other than that, the code in PermissionsModule duplicates the checks in LLClientView so there should be no change other than allowing group members to edit embedded notecards and scripts.
For all other asset types, the permission checking code in LLClientView continues to be used, pending refactoring of suitable permissions code
This means that 'share with group' will not yet work for prim inventory items other than notecards and scripts
* Adds GetTextureModule that implements the "GetTexture" capability, aka HTTP texture fetching. This is a significantly optimized path that does not require any server-side JPEG2000 decoding, texture priority queue, or UDP file transfer
* Sanity check for null reference in LLClientView.RefreshGroupMembership()
If serverside permissions are off then this works as expected. Previously, it was impossible for more than one person to edit such items even if permissions were off.
If serverside permissions are on then this works as expected if the object was created by an avatar who had the required group active.
However, if the group for the object is later set then the contained item is still not editable. This may be linked to a wider bug where the object is still not modifiable by the group anyway
If a full update is sent after the kill, the object remains as in the linden viewer but in an undeletable and unowned state until relog
This patch prevents this by recording kills in LLClientView
* Moved the SL asset type to content type conversion methods from ServerUtils to OpenSim.Framework.SLUtil
* Linked content type to asset type in AssetMetadata
Fixes: Undo, T-pose of others on login, modifiedBulletX works again, feet now stand on the ground instead of in the ground, adds checks to CombatModule. Adds: Redo, Land Undo, checks to agentUpdate (so one can not fall off of a region), more vehicle parts. Finishes almost all of LSL (1 function left, 2 events).
Direct flames and kudos to Revolution, please
Signed-off-by: Melanie <melanie@t-data.com>
These patch should allow people using systems that do not have their locale set to En_US or similar to use OpenSim without suffering effects such as being a million miles up in the air on login.
The problem was caused by parsing strings without forcing that parse to be En_US (hence different decimal and digit group symbols were causing problems).
Thanks very much to VikingErik for doing the legwork on this fix and phacelia for spotting it in the first place.
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
* Handle logout properly. This needed an addition to IClientAPI, because of how the logout packet is currently being handled -- the agent is being removed from the scene before the different event handlers are executed, which is broken.
When an object was deleted, the remove script instance call was aggregating the scripting events as normal.
This would queue a full update of the prim before the viewer was notifed of the deletion of that prim (QuitPacket)
On some occasions, the QuitPacket would be sent before the full update was dequeued and sent.
In principle, you would think that a viewer would ignore updates for deleted prims. But it appears that in the Linden viewer (1.23.5),
a prim update that arrives after the prim was deleted instead makes the deleted prim persist in the viewer. Such prims have no properties
and cannot be removed from the viewer except by a relog.
This change stops the prim event aggregation call if it's being deleted anyway, hence removing the spurious viewer-confusing update.
This merge was very conflicted. I think I got them all, but I can't be sure.
I had to merge to master or risk divergence to the point of unmergeability.
Diva Canto