Anybody knows what this means? Im getting it when playing a MPR with my InSim app connected. Right after getting this error my app times out.

Sounds like a asynchronous socket error. (WSAEWOULDBLOCK) It basically means that the socket is busy or waiting and it would tie up or block your program from doing other things. Usually you should just store what you have and wait until you get another event that says its safe to call receive again. I'm not sure what language you're using but hopefully that makes sense.. If not, give us more details, etc..

Thanks for your reply, re-reading my msg I wasnt very informative: it is LFS who is showing that message in big red letters, not my program, so theres not much I can do AFAIK.

Process is:

- Start my program (C#)
- Start LFS and open the insim port
- Go to replay/mpr/select a replay with lots of action (27 drivers)
- Everything seems to be working for about 45 seconds
- LFS shows INSIM ERROR: WOULD BLOCK
- My app times out and LFS frame rate drops to 5, I have to restart both LFS and my program.

I assume Scawen is showing the exception message as last resort in the case of unexpected socket exceptions, but I'd love to know if its my program who is causing it and why

Is your program continuing to receive packets?

I think WOULDBLOCK comes up if the sender keeps sending info but the receiver does not collect that info, so the buffers get full up and in this case, windows is not accepting any more info.

Another way to get WOULDBLOCK is if the sender just tried to send data faster than the socket could transmit it, until the buffers got full up that way.

Well that's my understanding of it and I have not specifically tested running an MPR to verify that LFS is not bugged. My first thought is that your program may have decided not to receive the data that is being sent to it. But maybe it's some kind of LFS InSim packet spamming when playing an MPR - which would be a bad bug.

I tried parsing the same replay with the same insim engine but in an app without UI and it seems to work properly, so I think the problem is definitely in my side, and that the bottleneck happens when the UI updater cant keep with the amount of packets received.

I'll keep testing and post here if I discover something wrong.

Hello, I found:

in the log of our league server (dedi X2). The server has "/insim <port>" line in its configuration, but no insim program was running during the race (actually any insim program never runs on the server). The error message is in the middle of the race. The replay recorded by the server. The server runs on linux, wine (I don't know the exact versions of wine ATM, but I can find it, if anyone interested).

I don't know exactly in which moment the error appeared, in the log it is between:

(lap 5)
and

(the leader is in the middle of lap 8).

That is OK. on a WOULDBLOCK, LFS can't send the data, so it stores it in a buffer.

When it's OK to send, it sends the data - "Cleared emergency store".

If this happenned all the time that would be a problem, but occasionally, it's just LFS successfully dealing with a non-fatal network error so that's ok.

It's like the post box is full, so you come back later, and you can post your letter.

I was surprised, that LFS dedi uses some TCP connection (I thought, that it uses UDP only). It is probably to the LFSWorld (statistics, PBs, ....), right? I'm just curious .

Latest insim uses TCP, if you have it enabled in your dedi, there you go

Quote from Kada_CZ :

I was surprised, that LFS dedi uses some TCP connection (I thought, that it uses UDP only). It is probably to the LFSWorld (statistics, PBs, ....), right? I'm just curious .

All LFS communication between host and guests is TCP, except for car position updates.

Without using TCP for most packets, there would be missing data and the guests would not stay in sync.

UDP is used for car positions, because if you miss this special case data, you don't want to try and correct that, you just want the new position.