Yeah, now it worked, to write a Post.
But its late so it will be a short one.

I want to write a short application using insim.
Now its the first time I use UDP.

So I have few Problems, I sent the ISI-Packet in main menu, the message appears (Port XXXXX...).
If I want to close LFS it went to hell Sound laggs...
If I sent two packets (ISI and ISC) it worked but I get three logg messages
Insim Init, Insim closed and after the closed one I got the message, that I sent a packet before ISI...

I dont think that this are bugs, so what went/ could went wrong

Here a short code part

First you need to send an ISI (InSim Init packet), and LFS should start listening to your app. Then send any packets you want and listen for them, but remember every 30-60 seconds to send some form of communication so that LFS doesnt close the connection after 2 minutes. When you're done then send an ISC (InSim Close packet).

Hopefully thats answered your question? Also don't forget you have to start InSim within LFS, or as an argument, wit /insim=port (or edit your cfg file).

No sry, am I so unclear?

I know what to send and so on, what I want and what the code part is, is to look if I make everything right.

After I send this two packets you will see that



that looks like 3 packets...

And if I send only ISI I cannot close LFS cause it hangs up.

Proof if you realy send only two packets. I have just test it, I send two packs ISI and ISC and I get only two messages

InSimInit: port <PORT>
InSimClose: Waiting for connection

nothing more

Edit: I used C

Quote from CLRS530 :


lfsSocket.sendMessage((char*)&insimRequest,sizeof(struct InSimPack));
lfsSocket.sendMessage((char*)&startInsim,sizeof(struct InSimInit));


You're sending the ISC before the ISI?

Ah ok just see. Your LFS hangs up. Could be you send LFS the wrong port, dont send the port you specifie in the cfg.txt you must send the port your application is listening.
If I send the same port in the ISI like LFS is listening my LFS hangs up too.

Edit: Or set the Port Value to 0 then LFS sends back to the port the ISI pack comes from.

No sry I posted it in the wrong order.
If I would send it to the incorrect port nothig would happened.

I send only this two packets, no more and if I send this two LFS didnt hang up but the 3 messages appears.
I have to do anything wrong...

Quote from CLRS530 :

And if I send only ISI I cannot close LFS cause it hangs up.

You send the InSimInit packet and then your LFS hangs up ? Am I right ?

If I send the ISI packet and no ISC after that and then I try to close LFS it hangs up...
But if I send both LFS works but I get 3 messages

Ah ok, I didnt understand that right.

I thought Your LFS hangs up in the moment you send the ISI packet.
I had that problem once because i set the Port value in the ISI packet wrong.

What do your InSimInit and InSimPack classes look like?

--
Rob

You mean structs?

The one from insim.txt...

Quote from CLRS530 :

You mean structs?

Uh...yeah...those...

I can't see anything in the code you've shown us. It sure looks like a spurious message is being sent after the "ISC" packet though.

--
Rob

Quote from CLRS530 :

I dont think that this are bugs, so what went/ could went wrong

Just a thought - You are sending structure, which MAY be different (Compiler optimization for aligned addresses) from InSim required structure ?

Compiler does not guarantee, that structure below is 3 bytes long !
(usually compilers would optimize it to 8 bytes)


Maybe you should try debugging a little and maybe take a look at #pragma PACK directive?

Yes sure, I debuged, the first structure has 24bytes and the second 8bytes...
Second I filtered the UDP packets, but only one 'sniffer' I tested showed the local packets.
There it looks like everything is ok.
But I could test only the one with the ISI packet, cause any bug (in my windows or this sniffer) appears and I had a blue screen

If anyone could test my program, that would be fine
I have no idea whats wrong

If LFS is freezing it makes me think that its sending data to the port it is listening on, therefore getting its own data and messing up. If you're sending stuff to port 49999, make sure you specify a different port in the ISI packet and not 0 either because I think that does the same thing..

Worth a shot?

Lol, that was it, both 'bugs' are gone .
Hmm, but I think that could be or better should be fixed from LFS?!?

That was what I mean !

Yeah, Hahni mentioned the 0 port thing above, and the docs say you can put port 0 (to send stuff back to the same port you sent on). To me that doesnt make much sense, and our experiences proved what it does.

Anyway, maybe Scawen has a good reason but for now the best practice is to specify a different port.

No no, nothing with Port 0.
I used the same Port for the Socket (where I sent ISI pack to)
and used the Port in the pack too.
that should be the same as to write port 0, yes.

But that should work shouldnt it?
Or LFS have to say at least it dont work and not hanging up or dont work like you think it should do.

In LFSLapper I always used 0 and didn't have any problems with it.

Ok, I will test it with Port 0..

EDIT: It works with Port 0, lol, but it didn´t worked to write the same port as the incoming one.
I think that should be fixed and handled same

EDIT2: I hope Scawen reads that, I won´t write it in the test patch sub...

You can have same port on same address opened twice ?

insim app: 127.0.0.1:49999 lfs:127.0.0.1:49999


I think what Scawen meant with port 0 is that whatever (random) local port is used for starting packet then lfs will send exactly to that port if you specify 0.

So 0 means:

insim app:127.0.0.1: x (free or binded udp port) <-first packet->lfs:127.0.0.1:49999
insim app:127.0.0.1: x <-any next packet->lfs:127.0.0.1:49999

If you use other than 0: y

insim app:127.0.0.1: x (free or binded udp port) <-first packet->lfs:127.0.0.1:49999
insim app:127.0.0.1: y <-any next packet->lfs:127.0.0.1:49999

Of course I might be wrong. Should trace the packets, but my head isn't clear now and it's time to sleep.

But where is the difference between Port 0 (back to the same port) and use the same port?
It makes for usage no sence to me

Quote from CLRS530 :

But where is the difference between Port 0 (back to the same port) and use the same port?
It makes for usage no sence to me

Maybe i've got it wrong, you're asking why you can't specify the exact same port as LFS is listening on as the port for responses in the ISI packet when you run everything on the same machine? Because it would make LFS send packets to itself.

Just like MonkOnHotTinRoof says, using 0 will make LFS respond to the originating port of the incoming packet, which is of course completely different from LFS' listening port.