|
Rune Osterham
Registered User
Join date: 20 Nov 2008
Posts: 1
|
09-20-2009 02:45
Hi, I have a question about the underlying system of SecondLife.
I have a function that breaks a block of large data into small envelopes and I use this function to break up large data items and send them via llRegionSay to other objects; some additional information in the envelope allows the target scripts to reconstruct the original data item. My question is, why not simply have a data enveloping and queuing system like this built into the SecondLife subsystem, given that any script writer could write functionality just like this to get around the 1023 byte limit?
Cheers Rune
|
|
Lear Cale
wordy bugger
Join date: 22 Aug 2007
Posts: 3,569
|
09-20-2009 09:28
Answer: because it wouldn't be "simple". It would complicate llSay() et. al, in terms of buffer management. It would entail a pretty big change to these functions as well as the chat subsystem.
This is based on my general understanding of software architecture and distributed communications, and not specific knowledge of SL's code.
|
|
Valerion Raymaker
Registered User
Join date: 7 Mar 2007
Posts: 60
|
09-21-2009 00:55
Why would you want to send such large data blocks around in Second Life? 1023 characters is 1 byte short of 1kB of data. Unless you're passing whole textures or notecards around, I can't see what you'll need multiple 1kB blocks of data for. Especially given that scripts have a 16kB / 64kB memory limit. Perhaps you can pass UUIDs instead?
In any event, it may also be considered abusive, depending on the number of them and the frequency. llRegionSay is designed to send short messages, and may (depending on the implementation LL did) need to wake up every script in the sim to see if it wants to hear the message.
If you really want, yes, you can implement a packeting system. TCP is a good example of this, with delivery guarantees added on as a bonus.
For reference, I have attached 1023 "0"'s to this post.
----------------------------------------------
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
|