Ok im using this insim from this forum and I keep getting

TCP Error: WOULDBLOCK
TCP ERROR: Cleared Emergency Store

I tried forwarding ports same thing
I tried changing insim ports from 29999 to 2999 same thing

Also everybody keeps timing out each time the insim is on

Can somebody please help me out

Currently I'm using hamachi to make the server and run the insim so that I can find all the problems and if I can I correct them then I will start the s2 host and use the insim.

PLEASE AND THANK YOU

"this insim"? there are many applications that use the INSIM protocol, which one are you referring to? AIRIO? lapper? one of the cruise INSIM's? you'll have to be more specific.

sorry about that im using the cruise insim lfs_external

Not sure how this works in correlation with InSim, but in general LFS does not allow any connections through Hamachi IP ranges. Maybe that's your problem.

There really is no reason at all for you to use Hamachi :rolleyes:

And why would you want to open an S2 host you couldn't even administrate properly?

I have had the same issue as the OP. The problem in my case was that the application was sending too much button packets at once(morpha helped me figure that out too so he should know :razz. That's why I had to code a function that helps me have a delay between each button or sequence of buttons that are being sent. And that's what you need... Unless the connection is so bad that it is impossible for the server to keep an insim connected along with users in it.

Hope that helps.

Hrm.. sending less information is not the correct way to handle that error. It works for now, but it's a slower solution than need be. A TCP wouldblock message means the socket is busy send/receiving/waiting and it would have to block (or freeze) your thread in order to do so. The appropriate response to that "error" is to wait for another successful message from the socket layer and resume where it left off. See this for a little more info: Winsock Programmer's FAQ. And a search for the C/C++ error constant WSAEWOULDBLOCK reveals tons of info. Also, here's a .NET 1.1 MS article on it.

Really, the programmer of the InSim library you're using should make this transparent and handle that error as needed. I do that in my old VB6 okSocket thats used in CSR and maybe Virtual LFS Dashboard. I can post some psuedo code later if interested.

Hope it helps!

Quote from Stuff :

Hrm.. sending less information is not the correct way to handle that error. It works for now, but it's a slower solution than need be. A TCP wouldblock message means the socket is busy send/receiving/waiting and it would have to block (or freeze) your thread in order to do so. The appropriate response to that "error" is to wait for another successful message from the socket layer and resume where it left off.

The problem isn't between the Insim application and LFS, it's between the LFS server and connected LFS clients. If you ask the LFS server to send too much data to a client (e.g. by sending lots of buttons) you're going to flood the buffer(s) and seemingly cause LFS to panic, dropping clients etc.

Ahh OK.. I assumed those errors were displayed in the error log of lfs_external and not in LFS itself. If the error messages are in LFS itself then I think this one is another bug to fix as like I (and the winsock FAQ) said, its a case of defensive programming and/or a choice of buffer sizes.. If it truly is a simple wouldblock message then it needs to be fixed. Otherwise LFS handled all the wouldblock messages it could, filled its maximum buffer, threw the wouldblock message (misleading in this case) and finally empties the buffer/store. Either way the wouldblock message needs to go away.

A technical explanation from Scawen would definitely help to clear some things up though. Until then, not much more we can do..