Totally!
Totally!
What would be the purpose of that table?
A Trackvote?
A Trackvote?
That is a nice idea - though I wouldn't make it a table, I'd make it buttons you could add, at the position you like, with parameters, something like :
struct Button
{
byte click_id; // button identifier for click packet
byte for_connection; // send to this connection id
byte style; // with button / centred text / etc...
byte spare;
byte l, t, r, b; // left, top, right, bottom
char text[64]; // button text
};
struct BClick
{
byte click_id;
byte from_connection;
byte sp2;
byte sp3;
};
struct Button
{
byte click_id; // button identifier for click packet
byte for_connection; // send to this connection id
byte style; // with button / centred text / etc...
byte spare;
byte l, t, r, b; // left, top, right, bottom
char text[64]; // button text
};
struct BClick
{
byte click_id;
byte from_connection;
byte sp2;
byte sp3;
};
New InSim protocol...
The request for the clickable interface constructed by InSim programs has got me thinking now, the current UDP based insim system and guaranteed delivery system is too clumsy and starting to result in too many packets flying around, and has a major drawback that the guaranteed delivery does not guarantee order. Also there is a well known problem that connections must be identified by user name comparisons, instead of a unique connection identifier assigned when the user connects - that is ok for licensed hosts but doesn't work on demo hosts where changing player name must be used instead, and doesn't help our insim programmers testing on a local network. So I'm thinking that a major overhaul is required, including a change to TCP instead of UDP, and using connection ID, not user name in packets that refer to a user.
All InSim packets would start with a consistent three bytes, specifying the size, the packet type and an optional request id (useful for individual clients making a request through an insim relay). Then a minimum of one data byte. For example :
struct IS_NCN // new connection
{
byte size; // 56
byte id; // packet identifier, from an enum (e.g. 28)
byte request_id; // zero unless this was sent in response to a request
byte conn_id; // unique identifier of new connection
char UName [24]; // username
char PName [24]; // nickname
byte Admin; // user is admin
byte TotalConns; // number of connections on host, including host
byte Sp2;
byte Sp3;
};
struct IS_CNL // conn leave
{
byte size; // 4
byte id; // packet identifier, from an enum (e.g. 29)
byte request_id; // not used for this packet - zero
byte conn_id; // unique identifier of leaving connection
};
So what do you think? I might leave some packets UDP based - the time based ones that report car positions, just like in LFS, if you miss one of those, you just want the next one, you don't want TCP tripping over itself trying to correct that kind of data.
All InSim packets would start with a consistent three bytes, specifying the size, the packet type and an optional request id (useful for individual clients making a request through an insim relay). Then a minimum of one data byte. For example :
struct IS_NCN // new connection
{
byte size; // 56
byte id; // packet identifier, from an enum (e.g. 28)
byte request_id; // zero unless this was sent in response to a request
byte conn_id; // unique identifier of new connection
char UName [24]; // username
char PName [24]; // nickname
byte Admin; // user is admin
byte TotalConns; // number of connections on host, including host
byte Sp2;
byte Sp3;
};
struct IS_CNL // conn leave
{
byte size; // 4
byte id; // packet identifier, from an enum (e.g. 29)
byte request_id; // not used for this packet - zero
byte conn_id; // unique identifier of leaving connection
};
So what do you think? I might leave some packets UDP based - the time based ones that report car positions, just like in LFS, if you miss one of those, you just want the next one, you don't want TCP tripping over itself trying to correct that kind of data.
I loathe the thought of recoding everything to TCP now i've got such comprehensive software in place, such a total overhaul is a lot of work. *grumble moan!* 
, but i'll do it.
There are some things that make sense to be TCP (SPX/LAP/MSO), and some things that make sense to be UDP (MCI).
Have you considered splitting insim down into more sub-systems like Outguage? The end-user uses one /insim 49999 port, but the software that connects then requests: Outguage; Messaging; Race Tracking; Car Tracking (MCI) etc on separate ports?
, but i'll do it.There are some things that make sense to be TCP (SPX/LAP/MSO), and some things that make sense to be UDP (MCI).
Have you considered splitting insim down into more sub-systems like Outguage? The end-user uses one /insim 49999 port, but the software that connects then requests: Outguage; Messaging; Race Tracking; Car Tracking (MCI) etc on separate ports?
Can you elaborate on request_id? What it is meant for.
First thing to say - it's totally optional - just provided for your convenience, if required, or if you want your software to make requests to an LFS host through a relay system.
Request ID is like, if you connected to the InSim relay server, Victor's program would send you a unique id on connection. Then, if you sent one of the packets that requests some info, like "send me a list of all connections", your program or the relay would insert your request_id into the request packet.
From LFS's viewpoint it's just an optional user defined packet identifier - whenever it gets such a request packet, it fills in your request id into the reply packet(s) and sends it back. Then Victor's relay program, for example, can direct the relayed packet to the required guest (instead of sending the requested packet to ALL connected clients as it does now). It also distinguishes between a new connection packet, and info about a connection requested by a connected InSim client. Basically use it for what you want, LFS just takes it and puts in into the requested packet(s).
So, request_id is always non-zero in a request packet. If request id in any outgoing packet is zero then it goes to all guests, if non-zero then it goes to the appropriate guest. It's just a simply way for LFS to support a single connection with multiple clients (e.g. Victor's InSim relay system which a lot of people use).
One thing that also occurred to me is that the TCP method, because it is connection oriented, would also make it easier to support multiple InSim clients on one host without using the relay system.
I suppose one option is to allow UDP as well - but without the guaranteed delivery system. That's ok on a local network where there is not usually any UDP packet loss anyway. But I'd have to unify the packets - i.e. use the same packets for the UDP and TCP versions - I can't support the whole old system and the new version as well. I think it would be easy to adapt your software that way, just using the slightly modified packet structures, and using connection unique id instead of "user name" to track things.
Assuming connection id stays unique, aside from a little hesitance over the prospect of moving from the current packet structure to a bstrings-style of packets, I actually really like the idea and fully embrace it
Connection ID is unique yes, from when there is a new connection, until that connection disconnects, but note that it is different from player's unique id (as player can be AI or can swap between connections, in the case of a driver swap). The connection unique ids are also conveniently unique with (i.e. never shared with) the player id's because they are assigned from the same pool.
I don't know what bstrings are but anyway, once your TCP packet receive function is in place (to make sure you have a whole packet from the stream before processing it) it should be easy because every packet is marked with a size and you don't need to know if you should or should not reply with an acknowledgement - you never do - another of the disadvantages of the old system, people's InSim programs were never forward compatible if I added any packets.
I don't know what bstrings are but anyway, once your TCP packet receive function is in place (to make sure you have a whole packet from the stream before processing it) it should be easy because every packet is marked with a size and you don't need to know if you should or should not reply with an acknowledgement - you never do - another of the disadvantages of the old system, people's InSim programs were never forward compatible if I added any packets.
Relays too eh, i'm going to have to think up a load of new features to stay ahead of the things you are implementing . Except that for now, I think I will stop all development until Insim has finished changing direction.
On TCP:
I've had problems in the past where the content of two bytes within a packet matches the HTML EOL marker when using TCP over the net (when it tested fine locally).
I can't say i'm keen on TCP as an extra 30 odd bytes or so on the packet header is a considerable ramp up in my bandwidth when I open the new server and run LFS servlets on each one, talking to one central program.
Having said that, TCP makes sense for MSO packets when dealing with a remote server, as the messages should appear in the right order, and it's reliability makes sense for race tracking.
However I'd certainly be happier if MCI data was available via UDP rather than TCP, just for the bandwidth saving alone - even if I did everything else with TCP.
. Except that for now, I think I will stop all development until Insim has finished changing direction.On TCP:
I've had problems in the past where the content of two bytes within a packet matches the HTML EOL marker when using TCP over the net (when it tested fine locally).
I can't say i'm keen on TCP as an extra 30 odd bytes or so on the packet header is a considerable ramp up in my bandwidth when I open the new server and run LFS servlets on each one, talking to one central program.
Having said that, TCP makes sense for MSO packets when dealing with a remote server, as the messages should appear in the right order, and it's reliability makes sense for race tracking.
However I'd certainly be happier if MCI data was available via UDP rather than TCP, just for the bandwidth saving alone - even if I did everything else with TCP.
I don't think that UIds should change at all. In the current version of InSim you have it changing for no apparent rhyme or reason. Once that person get's that UId it should be theirs for the life of the server instance. So for example if they should come back 2 weeks later and the server is still running with that same Instance they should get their old UId back.
Whats with a method some or all ego- shooter games I know use (Enemy Territory for example). It has a guid wich is stored locally and have to be saved also on the master server that it don´t has two the same.
If you delete the local file LFS has to send a new one and maybe can delete not used ids after half a year and send a new one for a user who tries to connect with a id wich isn´t availible.
It´s just a short idea from me and I didn´t think in any direction over that problem but the new system should be much easier to use for everyone then the one we have now.
The id could also be a sha key from the username wich makes it unique. The only problem wich have to be managed is that demo racers don´t have such a user name.
Maybe a system to see them with there physical address
If you delete the local file LFS has to send a new one and maybe can delete not used ids after half a year and send a new one for a user who tries to connect with a id wich isn´t availible.
It´s just a short idea from me and I didn´t think in any direction over that problem but the new system should be much easier to use for everyone then the one we have now.
The id could also be a sha key from the username wich makes it unique. The only problem wich have to be managed is that demo racers don´t have such a user name.
Maybe a system to see them with there physical address
You know, the more I think about the RequestID the more I wonder why you dont just have LFS handle more than one insim port?
Different software requires different packet data, for example LFSW might want MCI packets at one rate, and my 'traffic approaching' at another rate, with the current relaying system it's not possible to specify. With my relay system I adjust the MCI rate when LFSW connects to my management software, but wouldn't it be better to have LFSW just connect directly to LFS and have it's own ISI/ISC connection.
Currently there exists an incompatibility with relay systems where some of LFS' mutually exclusive packet types are used like MSO and the other one (I forget it's name, i've not used it).
In terms of bandwidth on the server it would make no difference to me as the relay sits on the same server, and I dont think many other people currently have a relay on their server anyway although I know i've been asked how to use LFSC for such a purpose (even though its not really designed for the job!).
If LFS supported multiple INSIM connections then we could do away with all the relays for using multiple insim applications.
Certainly those using the LFS clientside software would appreciate this, and a few people who've wanted to run multiple INSIM applications on their server would then be able too.
tbh the LFSW relay is a little impracticle at the moment as it cuts the connection too quickly when the server is lost, the 15th reconnection should really be 24hrs after connection is lost. Also it's maximum 'spectator' capacity could prove an issue for some events, such as the 24 hour race being organised for April. This 'unknown' factor invalidates the system. That and the custom packets mean software has to be written especially for it, and nobody does that.
Different software requires different packet data, for example LFSW might want MCI packets at one rate, and my 'traffic approaching' at another rate, with the current relaying system it's not possible to specify. With my relay system I adjust the MCI rate when LFSW connects to my management software, but wouldn't it be better to have LFSW just connect directly to LFS and have it's own ISI/ISC connection.
Currently there exists an incompatibility with relay systems where some of LFS' mutually exclusive packet types are used like MSO and the other one (I forget it's name, i've not used it).
In terms of bandwidth on the server it would make no difference to me as the relay sits on the same server, and I dont think many other people currently have a relay on their server anyway although I know i've been asked how to use LFSC for such a purpose (even though its not really designed for the job!).
If LFS supported multiple INSIM connections then we could do away with all the relays for using multiple insim applications.
Certainly those using the LFS clientside software would appreciate this, and a few people who've wanted to run multiple INSIM applications on their server would then be able too.
tbh the LFSW relay is a little impracticle at the moment as it cuts the connection too quickly when the server is lost, the 15th reconnection should really be 24hrs after connection is lost. Also it's maximum 'spectator' capacity could prove an issue for some events, such as the 24 hour race being organised for April. This 'unknown' factor invalidates the system. That and the custom packets mean software has to be written especially for it, and nobody does that.
You must have missed it up there where I did say that moving to TCP would allow multiple InSim connections to one instance of LFS.
No, it wouldn't remove the need for a relay - it would remove *some* of the needs for the relay - don't forget the relay allows 100s of people to connect because it's on our webserver which can provide traffic that would bring down an LFS host dealing with som many connections.
Im talking one one hand about making LFS support multiple InSim instances, and on the other hand by this extremely simple request ID also allowing far better relay support than we have now (one client's request doesn't swamp all other clients with unwanted and unexpected packets).
Well the ConnNum is quite useless because it's just the array index, when someone leaves, the end connection moves down into that ones slot, so now it has a new ConnNum (the same as the player who left). ConnNum is totally useless unless you maintain your connection lists exactly the same way as LFS does (and that's not very good without guaranteed packet order) The UniqueID will stay the same while that connection is there.
PlyNum and ConnNum are something to get rid of in the rewrite, just use ConnectionUniqueID and PlayerUniqueID.
I don't think it's that big a rewrite, it's about a day's work I guess for me to restructure (shrink) the packets, remove UName and PName where they aren't needed, where only one byte ConnectionID is needed.
It's just be a much cleaner and more streamlined system, allowing for future expansion, the addition of small packets which don't need this constant verifying procedure, etc. Unique ID for connections is an old request but couldn't be added easily due to compatibility. But it's not good everyone having to work around ropey old InSim's issues, better just get it right so we can move forward easilty in future - that's my opinion anyway.
PlyNum and ConnNum are something to get rid of in the rewrite, just use ConnectionUniqueID and PlayerUniqueID.
I don't think it's that big a rewrite, it's about a day's work I guess for me to restructure (shrink) the packets, remove UName and PName where they aren't needed, where only one byte ConnectionID is needed.
It's just be a much cleaner and more streamlined system, allowing for future expansion, the addition of small packets which don't need this constant verifying procedure, etc. Unique ID for connections is an old request but couldn't be added easily due to compatibility. But it's not good everyone having to work around ropey old InSim's issues, better just get it right so we can move forward easilty in future - that's my opinion anyway.
You are right, I did miss it.
Scawen 1 Becky 0
I'd love this update.
The idea with the buttons is great. I'm was also playing around lately to add a simple interface via insim to send race control messages for admins.
For this it would be create to have a textfield.
I think it would be enough if the chat input window is shown after a button is pressed, and the entered text is also transmitted with the button infos.
For this it would be create to have a textfield.
I think it would be enough if the chat input window is shown after a button is pressed, and the entered text is also transmitted with the button infos.
Yeah, this is going to be massive for the Live For Speed modding Community. All like 7 of us.
Scawen, I have some concerns over the release of insim v2, in that it will break my server management system. I'm most keen to have made the changes to the software before the patch moves from test to public so i'm ready for the udpate.
With everything else [LFS related] that I do it might be hard to fit in around your schedule, so would it be possible to give us some rough indication of when we'll get the test patch with this insim functionality and how long you'll from there 'very roughly' until it goes final.
I think for me, because i'm a bodge jobber at the best of times, and because of the size of my system, it might not be quick and easy to do this change.
If I can plan ahead I would be very grateful.
After some initial fear i'm actually rather excited to get my hands on it. I am such a nerd! No wonder i'm single.
With everything else [LFS related] that I do it might be hard to fit in around your schedule, so would it be possible to give us some rough indication of when we'll get the test patch with this insim functionality and how long you'll from there 'very roughly' until it goes final.
I think for me, because i'm a bodge jobber at the best of times, and because of the size of my system, it might not be quick and easy to do this change.
If I can plan ahead I would be very grateful.
After some initial fear i'm actually rather excited to get my hands on it. I am such a nerd! No wonder i'm single.
found here: http://www.lfsforum.net/showthread.php?p=397415#post397415
I have a similar problem, because I have to update my tools to manage the austrian championship. This time I'm lucky, because the last race is before patch X is released, when the schedule is right.
A nice feature would be that we can tell LFS which InSim version we want, so that with Patch X also old tools can work.
One other solution could be that multible LFS versions are supported. e.g. in the LFS directory a LFS_W.exe and a LFS_X.exe is located, and when the user connects to a server that runs the W version the LFS_W.exe is started, and vice versa.
But this would only make sense if the InSim changes constantly.
Tis the curse of the nerd, we are meant to be single.
I hope to release X on friday or saturday in just under two weeks time, though that depends how everything goes.
I've been on the case with the InSim updates the last two days and I think I am at a point where all the packets are converted and I've done a brief test - but the new button response system is not done and it still only works in UDP.
I'm considering giving it to you as it is right now, or some time this evening, so you can already start to convert your software to the new system. You would have to change your packet send and receive functions to TCP after that - but that's probably not a bad way to upgrade. I do want the day off tomorrow so it'll have to be this evening if it will be this weekend.
I've put a lot of documentation in this attached header file which replaces InSim.txt - if you can set your tab spacing to 4 spaces the file will be a lot easier to read. It's actually a .h file but I've renamed it to .txt so I can upload it here.
Please have a read through it and see if you spot any problems, or if anything is confusing before I release the first version to you (if you want it in this unfinished state - which is already as better than the old system except it has no packet guarantee system).
I've been on the case with the InSim updates the last two days and I think I am at a point where all the packets are converted and I've done a brief test - but the new button response system is not done and it still only works in UDP.
I'm considering giving it to you as it is right now, or some time this evening, so you can already start to convert your software to the new system. You would have to change your packet send and receive functions to TCP after that - but that's probably not a bad way to upgrade. I do want the day off tomorrow so it'll have to be this evening if it will be this weekend.
I've put a lot of documentation in this attached header file which replaces InSim.txt - if you can set your tab spacing to 4 spaces the file will be a lot easier to read. It's actually a .h file but I've renamed it to .txt so I can upload it here.
Please have a read through it and see if you spot any problems, or if anything is confusing before I release the first version to you (if you want it in this unfinished state - which is already as better than the old system except it has no packet guarantee system).
Being slightly uneducated I mostly go by feel, but the docs look ok from what I can see.
I see no reference to outguage in this document (maybe I is fick ), I dont use it for my stuff but when I did do an outguage application the lack of a header was frustrating (length wasnt unique) so that's worth considering but otherwise yes, go for it and i'll start rewritting my manager tonight and tomorrow and giving the new insim a real going over.
I see no reference to outguage in this document (maybe I is fick
), I dont use it for my stuff but when I did do an outguage application the lack of a header was frustrating (length wasnt unique) so that's worth considering but otherwise yes, go for it and i'll start rewritting my manager tonight and tomorrow and giving the new insim a real going over.This thread is closed
InSim changes needed (bug fixes, new packets needed, etc)
(151 posts, closed, started )
FGED GREDG RDFGDR GSFDG