ipc.write when WideFS client starts.

[Claude Troncy]

Hello Pete,

 

I need to initialize a data in the 66C0 free zone when my lua script starts from the WideFS client.

I noticed I have to wait 18 seconds before the ipc.write succeed. After that each ipc.write is immediuate.

 

I read that the write request from the client is not controled by wideserver, so I think there is something outside which cause this delay.

 

It is not important, but you certainly have an explanation.

 

The lua script init.

print ("start")

t = ipc.readUD(0X66C5)

while t ~= 150 do

ipc.writeUD(0X66C5,150)

t = ipc.readUD(0X66C5)

end

print ("end") 

 

The log

 5835 LUA: start

24321 LUA: end

 

Cheers

Claude

[Pete Dowson]

I need to initialize a data in the 66C0 free zone when my lua script starts from the WideFS client.

I noticed I have to wait 18 seconds before the ipc.write succeed. After that each ipc.write is immediuate.

 

Is this Lua script saved as "Initial.lua"? If so then it is run when WideClient is started, which could be long before there's even a connection.

 

If you have named it something else, then whilst 18 seconds seems a long time, it can be significant. There is always a lot of things being exchanged between Client and Server when things start up and the connection is made. On top of that the Server is struggling to get enough time to run because FS signals that it is "ready to fly" quite early, before things have really finished fully loading. 

 

If you want to see all the things happening in WideClient when it connects, set

 

Log=Debug

 

in the [user] section of the WideClient.ini file.

 

For you need to have 66D5 initialised to 150 at the start, I'd strongly recommend you do that on the Server, in the ipcReady.lua plug-in, which is automatically run. I do all of my offset and other initialisations there. This simplifies matters for all Clients.

 

Pete

[Claude Troncy]

 

 

Is this Lua script saved as "Initial.lua"?

No it is not.

 

 

 

For you need to have 66D5 initialised to 150 at the start, I'd strongly recommend you do that on the Server

 

Yes that's why it is not a big problem... But during the development process I thought it was easier to do it from the client.

Claude

 

The log

After startup, during 18 seconds I have repeatedly this in the log file.

 

    24320 MyReadStateData succeeded <M0:L0:C1:H253>

    24320 MyWriteStateData failed all retries! <M0:L0:C1:H253>

 

    24320 LocalReadWrite Entry <M1:L0:C1:H253>

 

    24320 Local message entry <M1:L0:C1:H253>

    24320 Processing request now ... <M1:L0:C1:H253>

    24320 Exiting ProcessRequestData <M1:L0:C1:H253>

    24320 FS6IPC message Exit2 <M1:L0:C1:H253>

 

    24320 MyReadStateData succeeded <M0:L0:C1:H253>

    24320 MyWriteStateData failed all retries! <M0:L0:C1:H253>

 

    24336 LocalReadWrite Entry <M1:L0:C1:H253>

 

    24336 Local message entry <M1:L0:C1:H253>

    24336 Processing request now ... <M1:L0:C1:H253>

    24336 Exiting ProcessRequestData <M1:L0:C1:H253>

    24336 FS6IPC message Exit2 <M1:L0:C1:H253>

 

And suddenly

 

24336 MyReadStateData succeeded <M0:L0:C1:H253>

 

    24336 LocalReadWrite Entry <M1:L0:C1:H253>

 

    24336 Local message entry <M1:L0:C1:H253>

    24336 Processing request now ... <M1:L0:C1:H253>

    24336 Exiting ProcessRequestData <M1:L0:C1:H253>

    24336 Adding Request Block now ... <M1:L0:C1:H253>

    24336 Exiting ProcessRequestData <M1:L0:C1:H253>

    24336 FS6IPC message Exit2 <M1:L0:C1:H253>

 

    24336 MyWriteStateData succeeded <M0:L0:C1:H253>

    24336 MyReadStateData met from local memory <M0:L0:C1:H253>

    24351 In MessageLoop <M0:L0:C1:H256>

 

    24351 MYSENDREQ Entry <M0:L0:C1:H255>

    24351 MYSENDREQ [ok=1] send() done: 27 of 27 bytes <M0:L0:C1:H255>

    24351 MYSENDREQ Exit <M0:L0:C1:H255>

    24351 In MessageLoop <M0:L0:C1:H255>

 

    24351 WSA_READ Entry <M0:L1:C1:H255>

    24351 WSA_READ FD_WRITE <M0:L1:C1:H255>

    24351 WSA_READ Exit1 <M0:L1:C1:H255>

 

    24367 In MessageLoop <M0:L0:C1:H255>

 

    24367 WSA_READ Entry <M0:L1:C1:H255>

    24367 WSA_READ FD_READ <M0:L1:C1:H255>

    24367 GetRecv() gets 47 <M0:L1:C1:H255>

    24367 GetRecv() packet 47 <M0:L1:C1:H255>

    24367 WSA_READ ProcessResponse <M0:L1:C1:H255>

    24367 GetRecv() done, zero <M0:L1:C1:H255>

    24367 WSA_READ free buffer <M0:L1:C1:H259>

    24367 WSA_READ Exit2 <M0:L1:C1:H259>

[Pete Dowson]

After startup, during 18 seconds I have repeatedly this in the log file.

 

    24320 MyReadStateData succeeded <M0:L0:C1:H253>

    24320 MyWriteStateData failed all retries! <M0:L0:C1:H253>

 

That can really only mean that it is getting no answer from the Server. It's probably simply because things are still pretty busy at that end. You could do similar logging in WideServer too (the parameter goes into the WideServer section of FSUIPC4.INI in that case), but I'm not sure how much you'd learn from it.

 

Pete

[Claude Troncy]

but I'm not sure how much you'd learn from it.

You are right... Just for info

I can see all my read

Read: Offset=66C5, Size=0004

 

and 18 seconds after the first one

Write: Offset=66C5, Size=0004

 

between each read a lot of

    43150 WM_MYSEND: Sent 46 bytes (timectr=0, i=1, blocked=0) (skt=5476) TCP

    43150 LAN Data Sent (skt=5476) TCP

          PREQ ulSize=35, ulTime=121, uSum=3281, fUsed=0

          60 05 00 FE 0C 00 E4 12 E2 09 72 A1 52 00 50 AC 

          62 3C FC 0F 00 FE 01 00 C2 24 C8 00 FE 04 00 C2 

          FA 0C 00 

 

and no error... So as you said certainly a lot of things to do on the server side

 

 

Claude