|
Hi Jim
Just as with 419, I did spend a little time contemplating if I should report this to the OpenSim guys or to you. I decided on the latter due to the following reasons: 1) Different simulators might possibly have different package sizes due to optimizations, especially in very customized grids, handling scenarioes where the first package received is actually the very last in the stream, i.e. it does not have a full buffer of std. size can be trouble some, the likelihood of this happing grows inversely proportional to the size of the asset. Of course it is all up to you to decide if you accept the patch, you have done a great job so far. Hey there:
Just to let you know.. I seem to be able to download texture assets from OpenSimulator regions using LibOMV. Here's an example: http://teravus.wmcv.com/googletester/idealistviewer20.jpg Applied in r2343, thanks! This is an unfortunate patch due to the additional and memory copies and fragmentation that will happen, but really just one more reason we need to move away from udp texture transfers entirely.
Just talked with OpenSim, and they correctly calculate transfer packets at 1000 bytes (and the first packet at 600 bytes):
size = m_asset.Data.Length - 600 - (1000 * (PacketCounter - 1)); Not sure where you are seeing the 1100 byte number, but it may be from an old revision of OpenSim or a protocol-breaking fork. Rolling this patch back to the old behavior. I just ran a few tests, I have a standalone open sim region at revision 7227
and it gave me the attached SIGSEV dump (dump 1), regardless of how OpenSim is implemented, I don't think that a SIGSEV is a safe implementation as it leads to some nasty eploits. I then tried the same codebase on my region running as part of OSGrid, running on r 7217 and got pretty much the same result: public void ConvertToStream() } the segmentation fault occurs when I invoke texture.Decode() Anything you want
Ubuntu 8-10 64 bit Without it, the transferred texture contains zero'es at the end of the file, matching the effect of transferring an 1,100 block size would have. I'm still wondering where the 1100 number came from. Other libomv-based applications connecting to OpenSim are working, and an OpenSim developer confirmed that the 1100 number doesn't show up in the OpenSim source code. I agree that your diagnosis of the problem seems accurate, but what led you to that specific number?
I'm using MonoDevelop as my platform, and there is no debugger !!! ... so I eventually made a debug build of libOMV, using the line numbers in the exception debug log, I finally went in and reactivated the debug logging code which is out commented in that section of the code. It is a bit outdated, but a little tweaking made it work alright!!!
original code --> asset.TransferData.Packet, asset.TransferData.Data.Length, transfer.Transferred, transfer.Size, transfer.ID.ToString())); <--new code gave this result |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
[patch] the asset download handler assumes that all but the last packets will always be 1,000 bytes long
Unless there is a compelling reason to do so, we try and stick to the wire standard (ie: we implement the protocol as per the working Linden Grid), deviating from that to support opensim or other implementations is unlikely as it would quickly become a nightmare to manage and support all the different clone grids people are starting to come out with.
Jim