This might not be it, but your version of code dates back to Jan 2, 2011. I've made a lot of fixes since then.
Each time one of the programs ends it is going to print statistics. Here are the ones from the bottom of your trace:
- Code: Select all
Tcp: Sent 105 Rcvd 102 Retrans 7 Seq/Ack errs 86 Dropped 0
Ip: TcpRcv: 102 UdpRcv: 24 IcmpRcv: 0 Frags: 0 CSumE: 0 ProtE: 0
Good: 0 Timeout: 0 NoSlots: 0 TooMany: 0 SizeOvr: 0
Packets: Sent: 115 Rcvd: 132 Dropped: 78 LowFreeBufCount: 0
So mTCP figured out that 7 packets were lost and retransmitted those. It also received 86 packets from the other side that had bad sequence numbers in them, implying the other side was seeing us drop packets.
Look at "Packets Dropped:" - that is 78. You are dropping more than half of the packets you received!
This might be a side effect of having the tracing on, so don't get too worried. But the next time you run look at the number of dropped packets. If you are on a really noisy network you might be just flooding the Jr with packets, and if the Jr doesn't process them fast enough it has to drop them on the floor.
(If you have a single connection to a mega-fast host the normal TCP/IP flow control will keep the PCjr from getting overrun. But if you have a lot of network traffic from unrelated machines the PCjr has to look at every single packet to make a judgement on whether the packet is important or not.)