I am in TCP mode.

I think it's seem to be a lfs issue. I try to put a better trace in LFSLapper. Wait please!

Gai-Luron

I have just send an email to the LFS developers, hope to hear back from them soon.

thank you for the info.
i hope it will be fixed very soon

Hi, I heard about a corrupt packet.

My guess is that it's not a corrupt packet, but split packets. I think that is more likely with the new buffering system. If a lot of data is being sent and not received quickly enough, you may get split packets.

I don't think I have explained that very well. But it is about TCP being just a stream of data, and there is no guarantee of getting a complete packet, or only one packet at a time. When you call "recv" you may get one packet, two packets, 50 packets, half a packet, 1 and a half packets, one packet and one byte of the next packet, etc, etc. It's safe because the size byte comes first.

LFS is MUCH more likely than before, to put MULTIPLE packets in a single "send". And if several packets are put into the buffer at once, filling it up, it is then likely to send the first 512 bytes, the end of which is unlikely to be on a packet boundary. That will be followed soon by another packet, with the end of that packet and whatever followed.

Don't read a packet until you have in your buffer enough for the given size byte.

I have nothing to go on, all I have heard is LFS Lapper and Airio may crash due to a corrupt packet. I can't study this or help until someone shows me the incoming data that caused the problem.

Hello Scawen,

I think you are rigth When you say it's probably an half packet. I supposed that. It's for that i've planed to put trace in lfslapper. You have change something in packet send ?
If yes, lfslapper, lfsstat and lfsrelax go to crash.
Bad new. I have no time to fix this quickly.
Lfslapper, lfsrelax and lfsstat users please wait, sorry for the incovenience.

Gai-luron

Hello,

Here a version of LFSLapper for Sjoerd 5.8.4.6 to try.

In this modified version, i bufferize stream in queue and read only if len of buffer queue is more or equal to len indicated by the first byte of the queue (len of next lfs packet). I think the reason of incomplete packet before this modified version of LFSLapper is that i'am not using block reading of tcp stream to not freeze LFSLapper loop. But before last lfs release i always receive a complete lfs packet in one shot.

LFSLapper 6 seems to work fine. The only difference is that in the 6 version the stream is received in a thread to avoid lagging issue (waiting for a complete packet in previous version of lapper block LFSLapper loop). In this case i can use block tcp receive and i think i receive in this way always a complete packet.

I hope my explanation are clear in my very poor english

Gai-Luron

Thank you so much for the updated version.
Just installed it on my server and will let you know if this has solved the problem.

Quote from Gai-Luron :

Hello,

Here a version of LFSLapper for Sjoerd 5.8.4.6 to try.

In this modified version, i bufferize stream in queue and read only if len of buffer queue is more or equal to len indicated by the first byte of the queue (len of next lfs packet). I think the reason of incomplete packet before this modified version of LFSLapper is that i'am not using block reading of tcp stream to not freeze LFSLapper loop. But before last lfs release i always receive a complete lfs packet in one shot.

LFSLapper 6 seems to work fine. The only difference is that in the 6 version the stream is received in a thread to avoid lagging issue (waiting for a complete packet in previous version of lapper block LFSLapper loop). In this case i can use block tcp receive and i think i receive in this way always a complete packet.

I hope my explanation are clear in my very poor english

Gai-Luron

I use 6.0.1.2 and its not working fine: see my posts above
if you can fix this version also i whould be happy

Ok,

I'm waiting for Sjoerd test to apply modification in my 6 release.

Gai-Luron

After nearly 24 hours of testing, not a single crash has happened, while some servers had a good number of people on them today.
So I think it is safe to say that your fix worked for Lapper 5.846
I will keep testing and let you know in case anything happens.

Do you have some trace on console screen?

Quote from Gai-Luron :

Do you have some trace on console screen?

No, not a single trace.

Hello,

Can you try this version. I found a potential bug in previous release.

Thank's


Gai-Luron

Okay, just installed 5.846b on my server.
Will keep you posted in case anything weird happens.

Quote from Scawen :

and Airio may crash due to a corrupt packet.

Eehh no.

I don't experience problems with Airio on this matter. I think this is isolated to Lapper.

Quote from 5ini5t3r :

Hi, I just updated my server's to 0.6D and I now get a message in the Airio log saying:

12.11.30 18:40:14 AIRIO ERROR : Index was outside the bounds of the array.
of type System.IndexOutOfRangeException
at LiveForSpeed.InSim.Airio.Datas.Read()
at LiveForSpeed.InSim.Airio.Airio.Main()

Does anyone have an clues as how to fix this please.

Thanks

EDIT: Problem solved

It's not me who said that. When i see the message the issue was not fixed. In ths message i guess that error seem to be a read error like LFSLapper.
If airio work fine, it's very good for you and all airio's user

Gai-Luron

Tonight Lapper (5.846b) on one of my servers crashed again with the following error:

---------

12/9/2012 7:54:14 PM

Lapper Instance 127.0.0.1/29991 abort!

StartIndex kan niet minder dan nul zijn.
Parameternaam: startIndex
mscorlib
bij System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
bij System.String.Substring(Int32 startIndex)
bij GLScript.GLApp.parseBackcall(SetOfVars GVAR, SetOfVars LVAR, unionVal val, ArrayList args)
bij GLScript.Parseur.getval(SetOfVars GVAR, SetOfVars LVAR, executeParsedFunction BC)
bij GLScript.Parseur.getval(SetOfVars GVAR, SetOfVars LVAR, executeParsedFunction BC)
bij GLScript.Parseur.getval(SetOfVars GVAR, SetOfVars LVAR, executeParsedFunction BC)
bij GLScript.GLApp.retrieveEvalVar(String funcName, TokenParse tkparse, TokenBuffer currTokenBuffer, SetOfVars GVAR, SetOfVars LVAR, Boolean breakFunc, Char& breakCar)
bij GLScript.GLApp.privExecuteTokensPart(Int32 level, String funcName, SetOfVars GCAR, SetOfVars LVAR, Boolean breakable, Boolean inSwitchCase, Int32 start, Int32 end)
bij GLScript.GLApp.privExecuteTokensPart(Int32 level, String funcName, SetOfVars GCAR, SetOfVars LVAR, Boolean breakable, Boolean inSwitchCase, Int32 start, Int32 end)
bij GLScript.GLApp.privExecuteTokensPart(Int32 level, String funcName, SetOfVars GCAR, SetOfVars LVAR, Boolean breakable, Boolean inSwitchCase, Int32 start, Int32 end)
bij GLScript.GLApp.privExecuteTokensPart(Int32 level, String funcName, SetOfVars GCAR, SetOfVars LVAR, Boolean breakable, Boolean inSwitchCase, Int32 start, Int32 end)
bij GLScript.GLApp.executeTokensPart(String funcName, SetOfVars GVAR, SetOfVars LVAR, Int32 start, Int32 end)
bij GLScript.GLApp.privExecuteFunction(String funcName, String[] argsVals)
bij GLScript.GLApp.parseBackcall(SetOfVars GVAR, SetOfVars LVAR, unionVal val, ArrayList args)
bij GLScript.Parseur.getval(SetOfVars GVAR, SetOfVars LVAR, executeParsedFunction BC)
bij GLScript.GLApp.retrieveEvalVar(String funcName, TokenParse tkparse, TokenBuffer currTokenBuffer, SetOfVars GVAR, SetOfVars LVAR, Boolean breakFunc, Char& breakCar)
bij GLScript.GLApp.privExecuteTokensPart(Int32 level, String funcName, SetOfVars GCAR, SetOfVars LVAR, Boolean breakable, Boolean inSwitchCase, Int32 start, Int32 end)
bij GLScript.GLApp.executeTokensPart(String funcName, SetOfVars GVAR, SetOfVars LVAR, Int32 start, Int32 end)
bij GLScript.GLApp.privExecuteFunction(String funcName, String[] argsVals)
bij GLScript.GLApp.executeFunction(String funcName, String[] argsVals)
bij Configurator.lexConfigurator.executeFunction(String funcName, infoPlayer pcurrInfoPlayer, String[] par)
bij LFSLapper.LFSClient.managePacket(NPL newPlayer)
bij LFSLapper.LFSClient.Loop(Connect insimConnection)
bij LFSLapper.LFSClient.doloop()
bij LFSLapper.LFSListen.Listen.goWorkMode()
bij LFSLapper.LFSListen.Listen.start()
System.String InternalSubStringWithChecks(Int32, Int32, Boolean)
Closing Instance...

---------

I think I've seen that crash before and I am not sure this is related to the network packets being send between LFS and Lapper.

No it's not a packet read error. Do you have trace on screen talking about incomplete packet ?
Is read error seem to be solved ?

Thank.

Robert

No, there wasn't anything on the console, except the message that it crashed.
I think you solved it, great work and thanks again my friend.

hi
uhm i have a small issue with arrays.

i have made a global var of the array and to be sure every string will be written properly i add some texts

GlobalVar $AddNewsBlockLine
FOR($NBnr=0;$NBnr<9;$NBnr=$NBnr+1)
$AddNewsBlockLine[$NBnr] = "Bla";
ENDFOR

In every line it shows "Bla" which is correct.
i add a differend string to one of the arrays in a another Sub and leave the rest of the arrays how they are.

$AddNewsBlockLine[0] = "New Text";

Then i go to the main sub and indeed the new text will be shown but the rest are cleared ????? The other arrays should still be saved right??

is this a bug or did i forgot something??

EDIT : Found solution >> http://www.lfsforum.net/showthread.php?p=1364926#post1364926

GlobalVar $AddNewsBlockLine;

without =

Edit: found a solution

http://www.lfsforum.net/showthread.php?p=1364926#post1364926

hi

How to use Japanese Characters in lapper??

-I have set file to UTF 8 format
-I have copied the big square ( Japanese codepage) from lfs into the file and putt the ^J infront.

But that doesnt work.

Does anyone have a solution for this??

Edit: @Gai-Luron your last patch is working perfect , no crash so far.

Quote from Bass-Driver :

hi

How to use Japanese Characters in lapper??

-I have set file to UTF 8 format
-I have copied the big square ( Japanese codepage) from lfs into the file and putt the ^J infront.

But that doesnt work.

Does anyone have a solution for this??

I've tried - and failed - to do other non standard Latin characters myself, so I know how frustrating this is!

I don't have a solution as such, but maybe a hint.

Way back in v5.849Beta, Gai incorporated his take on my version of a winnerflag add-on that I made into his lfslapper.lpr code (in later versions he separated it into it's own winnerflag.lpr add-on).

One of the lines he used for making 4 white squares had the following text;

"^1^L^H^9¡½ ¡½ ¡½ ¡½"

At first glance, you would think that the ^1 is the colour, but in fact, the square symbols come out white, so not sure what to make of that.

I assume the ^L is for Latin.

No idea what the rest is for I'm afraid!

It may be that you need to enter this sort of look-up code rather than enter a proper japanese symbol like え?