| www.ClassicTW.com https://mail.black-squirrel.com/ |
|
| packets https://mail.black-squirrel.com/viewtopic.php?f=15&t=34165 |
Page 1 of 1 |
| Author: | Tweety [ Tue Nov 12, 2013 2:00 am ] |
| Post subject: | packets |
i've been playing around with socket connections and found that often the text from trade wars is broken up quite a lot. You may have half a persons name in one packet, and then the next is the rest. or at least that is how it seems. sometimes you will get it all in one. with prompts, you get no line return, so you can't really read up until a line return because you will miss the prompt. so i thought, well i could buffer it up. and then read from the buffer to match text. but what i'm thinking is that i need a way to know when thats all thats coming. and if i can't rely on a line return to mark the end, how do i know what is actually the end? so i thought. well buffer it, then read. if a match take that part out of the buffer and continue from where i was matching the next. but what if the packets come in a different order? i'd have some crap in the buffer that never makes it out lol. would i end up with mis matched packets? i don't think there is a real order. they are just sent and when they arrive they arrive. I think that is how it works in tcp. what have people found that helps things out? |
|
| Author: | Mongoose [ Tue Nov 12, 2013 12:56 pm ] |
| Post subject: | Re: packets |
I struggled with this in Weapon M. There seems to be no rhyme or reason to where the game splits text into packets. And I think they could be split up further in transmission. There are a couple situations where not knowing what's coming leads to ambiguity about the meaning of what's already been received, but off the top of my head I can't remember what they are. I ended up having a flag in the parser that indicates when it's "at" a prompt. When the complete text of a prompt is received, it fires a prompt event and sets the flag true. When any additional text is received, the flag is cleared. This could be the echo of a command typed at the prompt, or a newline or clear line command preceding some other message. Then another prompt will be displayed. Tweety wrote: what if the packets come in a different order? That's something you don't need to worry about. TCP reassembles the packets and presents them to the application layer in the order they were sent. |
|
| Author: | Micro [ Sun Nov 17, 2013 4:20 pm ] |
| Post subject: | Re: packets |
You just have to store the partial lines, and wait for the next packet. If you received a partial line (no <CR>), you can go ahead and process the line if the connection is idle for about 100ms. You might also note that TradeWars sends the <CR><LF> in the wrong order. |
|
| Author: | Mongoose [ Mon Nov 18, 2013 4:32 pm ] |
| Post subject: | Re: packets |
It's even worse than that. The backwards LF + CR newlines show up outside the game, in TWGS menus. Inside the game, you get CR + ESC[0; + LF! My solution was to handle CR and LF separately. CR returns the cursor to column 0 (or column 1 in VT/ANSI's 1-based counting) and LF moves it to the next line. Then it doesn't matter which order they show up in. |
|
| Author: | Micro [ Tue Nov 19, 2013 3:35 pm ] |
| Post subject: | Re: packets |
Mongoose wrote: It's even worse than that. The backwards LF + CR newlines show up outside the game, in TWGS menus. Inside the game, you get CR + ESC[0; + LF! My solution was to handle CR and LF separately. CR returns the cursor to column 0 (or column 1 in VT/ANSI's 1-based counting) and LF moves it to the next line. Then it doesn't matter which order they show up in. I think that explains some rendering glitches I have been seeing. I was ignoring LF and doing a CR/LF for every CR, but I like your solution better. Do you still consider the CR the end of the line for lexical parsing? |
|
| Author: | Mongoose [ Tue Nov 19, 2013 6:45 pm ] |
| Post subject: | Re: packets |
I have the text stream going to two independent parsers: the data parser and the terminal parser. The terminal parser treats CRs and LFs separately as I described before. With few exceptions, the data parser doesn't care about newlines at all. Most of the patterns it's looking for are on a single line, and end when something that isn't part of the pattern shows up. Whether that's a newline or something else, it just ignores it. |
|
| Author: | Tweety [ Tue Nov 19, 2013 10:44 pm ] |
| Post subject: | Re: packets |
yeah, i'm leaning towards firing off events on matching text. I haven't worked on it for a bit though. |
|
| Author: | Micro [ Tue Nov 19, 2013 10:48 pm ] |
| Post subject: | Re: packets |
What language are you using? |
|
| Author: | Tweety [ Tue Nov 19, 2013 10:53 pm ] |
| Post subject: | Re: packets |
I'm using objective-c. So far I have a basic proxy server. just working on how to do some data parsing. then i'll look into building a interpreter of some sort to read .ts twx proxy files. and maybe then look at working with compiled versions. right now I have my mac app in the status bar kind of like twx proxy does in the status bar. with a menu system. its a hobby project 
|
|
| Author: | Kaus [ Fri Nov 22, 2013 5:21 pm ] |
| Post subject: | Re: packets |
Tweety which framework are you using in Objective -C, call me curious. |
|
| Author: | Tweety [ Fri Nov 22, 2013 6:30 pm ] |
| Post subject: | Re: packets |
It is a Cocoa app |
|
| Author: | Mongoose [ Fri Nov 22, 2013 8:00 pm ] |
| Post subject: | Re: packets |
I saw some Objective-C code once. Scarred me for life. 
|
|
| Author: | Tweety [ Sat Nov 23, 2013 2:17 am ] |
| Post subject: | Re: packets |
it is definitely a change from other languages i've learnt. naming conventions and some syntax. lots of [[brackets alloc] init]; lol |
|
| Page 1 of 1 | All times are UTC - 5 hours |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|