hi all

I'm trying to update my work to the new insim version.
I send the init packet, LFS seems to accept it and sends me immediately after a VER packet which my program can intercept and understand, but when my prog sends a tiny_none or a tiny_ver packet, LFS tells that they are sent before the ISI one which seemed to be successful just before..


what I forgot?

Maybe you open new connection somehow for each send?

I've not used the UDP connection in the new insim yet, but can I suggest you are responding to keep alive packets? Not responding will automatically close a valid connection.

Quote from hackerx :

Maybe you open new connection somehow for each send?

I'm using UDP, a "passive mode", no connection theoretically, but there might be a sender recognition problem.. If it's a dead-end, I'll switch to TCP

Quote from Becky Rose :

I've not used the UDP connection in the new insim yet, but can I suggest you are responding to keep alive packets? Not responding will automatically close a valid connection.

True but a tiny_ver or tiny_none is sent by my prog 0.5sec after the init one...

an out of topic question: UDP vs TCP, what are the differences? I've heard that UDP is potentially faster

Quote from Bogey Jammer :

an out of topic question: UDP vs TCP, what are the differences? I've heard that UDP is potentially faster

This seems to be the best (and most to the point) description I have found.

Edit: and another.

Tim

It seems like you are doing the same Mistake I did until riskredruM showed me how it works
I reinitialized my UDP Socket everytime I sent a Packet. If you do this every UDP Packet you send is sent from another Source Port. Because of this LFS does not know that the UDP Packet came from the same Program which opened the Insim System.

Use a Tool like Wireshark and if I am right you will see a increase of 1 in the Sourceport of each UDP Packet you send.

Edit: What I wrote is what hackerx wrote before... just a bit longer LOL

Quote from Bogey Jammer :

UDP vs TCP, what are the differences? I've heard that UDP is potentially faster

With UDP packets arrive quickly, but they are unreliable. They can arrive out of sync and sometimes not arrive at all. If your main concern is speed then UDP wtfpwns.

TCP is much slower, but the delivery of the packets is guaranteed. They arrive correctly and in the same order that they were sent (which is the cause of the slowness). If your focus is data-integrity then TCP omgwtfroxors!

UDP = fast but dodgy. TCP = slow but reliable.

There also could be some programming problems.
If you use for example different threads in your program it could be that one thread opens the channel to InSim, but before the intialising ISI packet ist sent another thread that uses the connection sends a request for another packet.

Set a breakpoint at the send routine an have a look at:
1. Which source port do you use (buedi mentioned it already)
2. The order of the packets you send. Escpacially, if the ISI packet is really the very first you send. In my Java program I use many threads and under certain circumstances I had a race condition where the ISI packet was not the first packet that was sent.

The difference between UDP and TCP is simple:
1. UDP has no mechanism to check if the packets you send really arrive.TCP is trusted. The packet you send will be recieved. Simplified you can say that UDP is "Fire and forget" and TCP is a protocol with verifying that a packet that is sent will arrive at the other end. Because of the TCP protocol nature TCP is slower than UDP but therefore reliable.
2. UDP ist packet oriented. TCP ist stream oriented. With UDP you know where a packet begins and a packet ends. TCP is a constant flow of data. The most common problem with TCP is that only the first packet in the recieve buffer is handled. But due to the nature of TCP there can be multiple packets in the recieve buffer and also be splitted LFS packets.

Quote from LupusC :

There also could be some programming problems.
If you use for example different threads in your program it could be that one thread opens the channel to InSim, but before the intialising ISI packet ist sent another thread that uses the connection sends a request for another packet.

In that instance surely you set a "connected" boolean member variable, then use mutuxes to ensure it doesn't get erroneously set/unset by multiple threads, and then only send data once the connected variable is set to true (when a connection has actually been established).

Naturally pretty simple to implement with TCP InSim.. slightly trickier with UDP since it's stateless, but it could be faked by sending an ISI followed by an IS_VER request and then listening for the corresponding IS_VER reply, then setting the connected member?

Quote from the_angry_angel :

...Naturally pretty simple to implement with TCP InSim.. slightly trickier with UDP since it's stateless, but it could be faked by sending an ISI followed by an IS_VER request and then listening for the corresponding IS_VER reply, then setting the connected member?

Or even better: set a request id in the ini and wait for the Version response to the ini packet
ReqI //If non-zero LFS will send an IS_VER packet

Exactly

I think that buedi pointed the problem, I close the socket every time I send a packet, now to confirm that I must change all my network part architecture. That takes me the most time to do it


Thanks for the TCP/UDP difference informations

EDIT:
I just made an experience consisting to send the init packet and a tiny_none after, without closing the socket, and LFS still doesn't want the second one. I suspect python language doesn't allow to send UDP packet via a fix port. I can't confirm since I didn't managed to make Wireshark to listen at 'localhost' and check the sending port numbers.

conclusion: I switch to TCP :chicken:

There is one other difference.

Whenever you send a data packet a 'header' is attached which contains all the routing information. The TCP header contains slightly more information in order to make the guaranteed and ordered delivery system. My understanding is that it is 96 bytes, and UDP's is 65 bytes. I may be a few bytes out either way, but the point is TCP will use more bandwidth up over time.

You can get the benefits of both with insim, by connecting with TCP and using UDP for the frequent but non-essential MCI + NLP structs . I plan to make use of this feature myself.

Quote :

I just made an experience consisting to send the init packet and a tiny_none after, without closing the socket, and LFS still doesn't want the second one. I suspect python language doesn't allow to send UDP packet via a fix port. I can't confirm since I didn't managed to make Wireshark to listen at 'localhost' and check the sending port numbers.

Hmm... I cannot imagine it is a Python problem, as sockets under Python should not really act any differently to those under a different language. It does sound more like a problem with your own code. Maybe if you posted some of your code we could have a look and see what the problem is. I really don't think UDP under Python would have any fundamental difference from UDP under another language, I mean UDP is pretty standard as a protocol.

Posting my code should not be very helpful, there are too many interactions in it..
I think so that Python manages socket like the other languages, but it doesn't let me too choose the sending port, which can be the problem.. or maybe a solution exists but I've not found it yet.

Why do you want to choose the sending port? Your program acts as a client program so the sending port is not of interrest.

You also do not select a sending port for Firefox or the IE (ok this is TCP, but also only a client). Googling I found this page http://evolt.org/node/60276. I dont't know if the program is correct but IMHO it shows the difference between client an server programming.

Finally, I just succeeded to send two consecutive paquets to LFS in UDP mode.

The last condition was to not close my thread which manages the packets sendings, in addition to keep the socket open.

there's a mess in my code after all these experiences, but I'm now relaxed I can continue my work.

Thanks for all who helped me (all the posters above )