Page 1 of 1
| Track circuit occupancy with no alteration to signalling 27/11/2013 at 21:22 #52080 | |
CTCThiago
232 posts |
 Hello Guys, In a multiplayer session, i see a TC Occupied with no alteration in signalling, but others players not (I'm in client). note: this is not a train. This is a bug or it happens to you anytime before? Cheers Thiago. Post has attachments. Log in to view them. Last edited: 27/11/2013 at 21:22 by CTCThiago Log in to reply |
| Track circuit occupancy with no alteration to signalling 27/11/2013 at 21:41 #52081 | |
JamesN
1608 posts |
Potential Bug, under investigation
Last edited: 27/11/2013 at 21:46 by JamesN Log in to reply |
| Track circuit occupancy with no alteration to signalling 27/11/2013 at 22:26 #52083 | |
|
AndyG
1842 posts |
Most likely to be a connection glitch, with some loss of data. Note that the signal in rear of the red TC is still showing a proceed aspect, which implies that the host server is still correct. It should get back into synchronization when the next real train passes through. I've encountered it a couple of times as a client, seems to be related to weak/slow connections, or when another client connects. I can only help one person a day. Today's not your day. Tomorrow doesn't look too good either. Last edited: 27/11/2013 at 22:29 by AndyG Log in to reply The following user said thank you: CTCThiago |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 02:08 #52090 | |
Temple Meads
307 posts |
I noticed last night, while in a KX MP game, that some small elements of the white 'route set' indicators on track circuits were still showing as 'route set', even though no route was set over them, setting a new route cured it though. Is this likely to also be a connection glitch? Username TIM in multiplayer Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 05:19 #52093 | |
|
alvinhochun
249 posts |
" said:Most likely to be a connection glitch, with some loss of data. Doesn't SimSig use TCP? I think TCP is stream-oriented and has built-in ack mechanism to make sure data is transmitted in order so no data can be lost. Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 09:03 #52098 | |
|
sorabain
72 posts |
TCP wont help if the connection is dropped and re-established via a new socket on the client-side; then you need some additional application-level sequencing to notice and set about filling the gap. Not particularly familiar with this sim but funny how there's a double yellow preceding a green too.. i guess the double yellow is correct and the green should be single yellow, then red just before the occupied TC etc Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 09:26 #52099 | |
postal
5265 posts |
" said:I noticed last night, while in a KX MP game, that some small elements of the white 'route set' indicators on track circuits were still showing as 'route set', even though no route was set over them, setting a new route cured it though.I presume this is not the same as white elements showing over points where no route is set to indicate that they are flank-locked by a movement on an adjacent line. “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 15:36 #52106 | |
|
Stephen Fulcher
2084 posts |
The signal showing the "wrong" YY aspect could also be a symptom of AndyG's theory. If the host computer is correct, then it is likely not a bug with the sim. Like Andy, I have seen some strange indications as a client that the host has reported are normal. Out of interest, did every client see this phenomenon or just the one? Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 16:18 #52108 | |
|
Temple Meads
307 posts |
" said:" said:Nope, this appeared to be random, and I can't say I've ever noticed it before.I noticed last night, while in a KX MP game, that some small elements of the white 'route set' indicators on track circuits were still showing as 'route set', even though no route was set over them, setting a new route cured it though.I presume this is not the same as white elements showing over points where no route is set to indicate that they are flank-locked by a movement on an adjacent line. Will grab a screenshot if I notice it again. Username TIM in multiplayer Log in to reply |
| Track circuit occupancy with no alteration to signalling 28/11/2013 at 16:23 #52110 | |
GeoffM
6377 posts 
|
" said:In a multiplayer session, i see a TC Occupied with no alteration in signalling, but others players not (I'm in client).I read this as the OP was the only person to have this track showing occupied, i.e. other clients and the server showed correctly. Therefore I would assume there was a missed message somehow. TCP is fairly reliable but it's not perfect, particularly if a particular hop is busy. SimSig Boss Log in to reply The following user said thank you: CTCThiago |
| Track circuit occupancy with no alteration to signalling 29/11/2013 at 12:54 #52142 | |
|
clive
2789 posts |
" said:TCP is a lot more reliable than these sort of rates imply. I suspect there's an issue with the Delphi TCP stack, but no investigations have been done yet. Log in to reply |
| Track circuit occupancy with no alteration to signalling 29/11/2013 at 14:26 #52147 | |
|
alvinhochun
249 posts |
" said:I suspect there's an issue with the Delphi TCP stack I guess the chance of this is not very high, a major bug in a major runtime library which could have already affected a lot of people but yet to be found? " said: TCP wont help if the connection is dropped and re-established via a new socket on the client-side; then you need some additional application-level sequencing to notice and set about filling the gap. Not sure but I've never seen SimSig client automatically reconnect to the server when connection is lost. Log in to reply |
| Track circuit occupancy with no alteration to signalling 03/12/2013 at 16:15 #52357 | |
|
clive
2789 posts |
" said:" said:True, but I can't see where else the problem could be.I suspect there's an issue with the Delphi TCP stack To investigate properly requires finding an environment where these problems happen and then running a TCP sniffer on the link. Then I could analyze the logs to find out what's going wrong. But without that or a smoking gun I don't know where we go next. Log in to reply |
| Track circuit occupancy with no alteration to signalling 03/12/2013 at 17:42 #52366 | |
|
GeoffM
6377 posts
|
" said:" said:The Delphi side of things is mostly just a wrapper for Windows calls.TCP is a lot more reliable than these sort of rates imply. I suspect there's an issue with the Delphi TCP stack, but no investigations have been done yet. All I meant by my reference was that if, for example, you're hammering your broadband connection then the chances of packets being dropped increases. We're talking two home networks and a whole bunch of routing between the UK and Brazil in this particular case. :evil: Maybe the NSA corrupted a packet? :silly: SimSig Boss Log in to reply |
| Track circuit occupancy with no alteration to signalling 03/12/2013 at 17:55 #52367 | |
|
sorabain
72 posts |
Is the front end entirely single-threaded? Wondering if it could be due to unsynchronized reading/writing of the same fields across multiple threads. I have all sorts of "fun" with memory barriers at work...
Log in to reply |
| Track circuit occupancy with no alteration to signalling 03/12/2013 at 18:55 #52369 | |
|
AndyG
1842 posts |
" said:....All I meant by my reference was that if, for example, you're hammering your broadband connection then the chances of packets being dropped increases. We're talking two home networks and a whole bunch of routing between the UK and Brazil in this particular case.I also think it's to do with a busy network. Once as a client on Bristol, I had several instances fairly close together, could be associated with another client connecting, and another symptom can be a short hang, or freeze-up which is usually followed by a disconnection[sup]1[/sup]. I suspect the likes of a Skype/Teamspeak connection doesn't help the cause either. [sup]1[/sup] The reload time on a loader sim is a nuisance here, could do with a straight 'reconnect' maybe? I can only help one person a day. Today's not your day. Tomorrow doesn't look too good either. Last edited: 03/12/2013 at 18:56 by AndyG Reason: typo Log in to reply |
| Track circuit occupancy with no alteration to signalling 03/12/2013 at 19:29 #52370 | |
|
GeoffM
6377 posts
|
" said:Is the front end entirely single-threaded? Wondering if it could be due to unsynchronized reading/writing of the same fields across multiple threads. I have all sorts of "fun" with memory barriers at work...The data is read from the socket and then put into a queue. The main thread then picks up the messages off the queue. However, I do see an extra thing I can do just to be certain. " said: The reload time on a loader sim is a nuisance here, could do with a straight 'reconnect' maybe?Already on the list (reconnect); however, some testers have a version that reportedly loads up in half the time of 4.0.14, and in some cases even better than that. SimSig Boss Log in to reply |
| Track circuit occupancy with no alteration to signalling 05/12/2013 at 09:06 #52420 | |
|
alvinhochun
249 posts |
" said:To investigate properly requires finding an environment where these problems happen and then running a TCP sniffer on the link. Then I could analyze the logs to find out what's going wrong. But without that or a smoking gun I don't know where we go next. Perhaps you can add an option in SimSig to dump the TCP stream and do it on both the client and server, then later compare them to see if they match? This require some extra coding, but should make it easier for normal users to help debugging. Log in to reply |
| Track circuit occupancy with no alteration to signalling 05/12/2013 at 17:59 #52436 | |
|
Forest Pines
525 posts |
Or just work out suitable instructions for getting testers to run Wireshark with consistent settings and get them to send the logs in!
Log in to reply |
| Track circuit occupancy with no alteration to signalling 06/12/2013 at 13:01 #52468 | |
|
clive
2789 posts |
" said:" said:That might be a later stage, but getting over-the-wire logs is less intrusive and gives us a clue as to where the problem lies. For example, the logs you describe won't distinguish between a message not sent and one lost in transit without TCP realizing. A wire log will tell us which end lost the message.To investigate properly requires finding an environment where these problems happen and then running a TCP sniffer on the link. Then I could analyze the logs to find out what's going wrong. But without that or a smoking gun I don't know where we go next. Log in to reply |