llEmail how big is a byte?

The wiki page on LlEmail

http://wiki.secondlife.com/wiki/LlEmail


says "The entire message (including the address, subject and other miscellaneous fields) can't be longer than 4096 bytes combined."

I'm not sure how to measure this.

How much text equals 4096 bytes? Is one letter or space equal to one byte?

For a string it is (llStringLength(string) * 2) + 5

+5? Is that based on llGetFreeMemory() tests? That may not be the same as the number of bytes counted in the transfer. I would also suspect that the transfer encoding for e-mail is UTF-8, though I haven't tested that. So there would be a question of whether the byte count is tested before or after re-encoding and such.

There's also no way that I know of to figure out how big the headers and such are, though maybe some processing on the delivered e-mails could help us figure it out (remove headers inserted by intermediate parties in the mail delivery system, etc.). The way I have handled this in the past is just to break things up into chunks that are very likely below the limit, like under 2k characters. Seems to have worked fine.

The internal encoding of text in Mono is Unicode, 16 bits per character.

The internal encoding of text in LSL2 is UTF-8, 8-40 bits per character.

The external encoding of text in LLEmail is UTF-8 with a content transfer encoding, probably quoted-printable. 8-120 bits per character.

Thanks Argent. Now to re phrase the OP's question given that info, how many characters can we reasonably expect to send as an email from Mono?

do a test yourself make a very long string, and send it via email to another objects.. get the string length that is given in the email event. with headers and stuff included. If you want add in an artificial break for the region if you want to get specific. It'll change because the header length is dynamic depending on your region and location.

Ok did the test myself, and I have yet to hit the limit for the cutoff of an email before running into a stack heap.

Sender

string address = "primkey@lsl.secondlife.com"; //Change primkey to the prims UUID that you want to send the email too
string message = "";

default
{
    state_entry()
    {
        integer maxlength = 415;
        integer index = 0;
        for(index; index < maxlength; index++)
        {
            message += "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
        }
        llSay(0, "message length is " + (string) llStringLength(message) + " free memory is: " + (string) llGetFreeMemory());
    }

    touch_start(integer total_number)
    {
        llEmail(address, "", message);
    }
}

Receiver

default
{
    state_entry()
    {
       llSetTimerEvent(1);
    }

    touch_start(integer total_number)
    {
        llSay(0, (string) llGetKey());
    }
    
    timer()
    {
        llGetNextEmail("", "");
    }
    
    email(string time, string address, string subj, string message, integer num_left)
    {
        llOwnerSay("message length = " + (string) llStringLength(message));
    }

}

So, unless I'm wrong, (which is quite possible ) it seems that email is restricted by how much memory you have available in your script.

was that in Mono?
Now the equation is even more confusing as it implies there is no limit to an email other than your available memory. I have personally used it for the past few years with no problem and no regard to the limits but I have been sending relatively small amounts of data. As my applications grow so does my data volume so it would be nice to have a definitive answer, but LL are not likely to give one
Thanks for testing Lazink.

Yes that was mono

I ran a few tests as well: Here are the results;

Both Sender & Receiver Compiled in MONO.

PROCESS 1: (Generate & Send Data to Receiver)

Total cycle ( 415 iterations ) Generated:
[16:48] Test Sender: message length is 25712 free memory is: 7938

(uncorrected llGetFreeMemory())

Last 60 chars of the message:
bcdefghijklmnopqrstuvwxyABCDEFGHIJKLMNOPQRSTUVWXY_7k(12.33%)

Where 7k = FreeMem(percentage)


PROCESS 2: (Message receiver by Receiver Prim)

Rcvr prim tells us the string received was:
[16:48] Receiver: message length = 25804

The last last 60 chars of the message:
[16:48] Receiver: bcdefghijklmnopqrstuvwxyABCDEFGHIJKLMNOPQRSTUVWXY_7k(12.33%)


PROCESS 3: (Email then sent from Rcvr Prim to my Home E-Mail Address)
This includes :

Object-Name: Receiver
Region: xxxxxxxxxx (######, ######)
Local-Position: (###, ##, ##)

Plus the message

Total Max Length sent to my E-Mail was MaxLen = 858 characters.


OBSERVATIONS:
I pushed the limit sending to my home e-mail starting @ string length 512 to 2048 and the system always capped out at 858 characters out of SLMail.

I also tested to see what would happen if I sent the full string, it simply choked (likely due to throttle) and nothing was received at all, just an empty e-mail.

Sending Internally seems to be no issue provided that there is enough memory capacity remaining to handle the inbound data.

Also of note, the formerly accepted 2 second delay for sending does not seem to be an issue but the receiving delay is still there but it does not appear to be 10 seconds anymore either.

Note: The prims were located a few metres apart, I believe that when sending from one host sim to another, the effects of the data transfer would be felt because now you are sending between two physical systems.

Tests were performed on a MainLand Sim with Medium Low population and activity. I'm sure that a heavy sim would lag the processing somewhat but I do not think too significantly.

-----
Hope this information helps to answer some questions and ideas.
WhiteStar

Thanks WhiteStar,

Very useful info. I an using it to send data to Gmail and I am probably dangerously close to the 858 character limit. Time for me to revisit that application and put in some test code to prevent Data disappearing in to the void.

One thing to remember about email is that it does not have guaranteed delivery, even when SL is not involved. It is simply a best effort system. So don't use email for data that absolutely cannot be lost.

Your very right Hooten,

Although, while LL makes no guarantees, I've found it to be pretty reliable & consistent. I in fact have my IM's forwarded to my WhiteStar e-mail account and so I have systems which report things to me via llInstantMessage and they always come through without issue.

Very:
Yes.. I started tinkering with a little ditty to check the string lengths and calculate the variables. Here is a rough working thing-a-ma-bob that I am playing with, maybe some others can chime in and we can make a "plug-in" to help us all from tripping on the limits.
** This is really rough, just a Thought Process underway **

test_mail_length(string mail_out)
{
//Object-Name: *prim* 13 characters + objname
//Region: *simname* (*simpos.x*, *simpos.y*) 6 characters + region info
//Local-Position: (*primpos.x*, *primpos.y*, *primpos.z*) 14 characters + local pos
// +2 for 2 returns = 35 chars PLUS *extras*
//*message*

vector mypos = llGetPos();

string mail_head = "Object-Name: "+llGetObjectName()+
"\nRegion: "+llGetRegionName()+" \n"+
"Local-Position: ("+(string)llRound(mypos.x)+", "+(string)llRound(mypos.y)+", "+(string)llRound(mypos.z)+"\n\n";

integer headLen = (llStringLength(mail_head)+16); //adding the (*simpos.x*, *simpos.y)
integer mail_out_Len = llStringLength(mail_out);
integer tot_mail_Len = headLen + mail_out_Len;

llOwnerSay("\n"+mail_head+"\nHead Length: "+(string)headLen+"\nBody Length: "+(string)mail_out_Len+"\nTotal Length: "+(string)tot_mail_Len);

}
I'm sure there is a more "elegant" solution that can be derrived.
WhiteStar

I just Looked at one of the larger emails sent from LSL to my Gmail account, did a copy paste of the body into word and ran the count. I get:

Pages 2
Words 239
Characters (no spaces) 1,077
Characters (with spaces) 1,315
Paragraphs 1
Lines 61

The message prior to that one did not arrive so I assume it tripped the limit.
The body was a list of people visiting in that hour, in this case 56, so because names can vary in length I think I will split it into 2 messages if it is reporting on more than 50 people.
Hopefully that will be a safe number.

just out of interest it would appear that the largest I have received to date had 1336 characters in the Message body and represented the details of 57 people. I know I have had higher counts than that so the messages for larger than 57 people are being swallowed

Thanks Very:

Interesting results, when I have some time (after the weekend) not in world much on weekends, I'll have another go at some more tests.

I think we are going to have to find / develop some type of test "module" that will determine just how much can be sent.

The Mail Headers have a fixed amount of predefine info, + the variable quantities such as region name, location etc....

The Message Body is also variable BUT... cumulatively there is a max that will send & be received correctly. In-World this does not "seem" to matter much at this time but out-world mail is the issue.

I think I can calculate the header ok with my previously posted header calc. The message is another item to verify and keep consistent.

I was thinking that some tricks could be used to increase the output limit a a tad. for instance, temporarily capturing ObjName and renaming it to :, send mail, then reset name, maybe some other trickery can be used to max up the data out.

There is of course certain issues that would arise from such, related to Perms & whatnot on purchased products...

TTFN
WhiteStar

I agree with Whitestar, I've seen more reliability from SL emails then I have from http_response.