About Monkey 2 › Forums › Monkey 2 Code Library › Successful TCP Client/Server Separation
Tagged: basic chat, tcp
This topic contains 2 replies, has 2 voices, and was last updated by 
 scurty 1 year, 8 months ago.
- 
		AuthorPosts
 - 
		
			
				
July 12, 2017 at 2:12 am #9263
Hello, this isn’t really all that Stable but I’ve managed to separate the TCP Client/Server App and still have them talk on my local machine. However, it get’s really crashy when you start them on two different machines. I assume this is because of my attempt at a request based communication setup. Remove that, and it should still work.
This supports Multiple Clients, Hacky File Transfer via “LoadString()” and Client Tracking in a “Peer List” variable.
Tested on Android, Windows 10, and Windows 7. (Tried Linux but it wasn’t compiling but I know why) using MX2 1.1.04Please submit any ideas to help make this more stable across Machines. x’D I’m lost at the moment.
Edit: I barely know anything about how the TCP lib works, so this it probably horribly coded. Aha
Edit #2: As far as I know, the only issue is high amounts of traffic, it seems to crash under heavy load.
Again, I think this is due to trying to escape the fiber through encapsulation and simple aggregation to hide the complexity, since in doing so I’m sure you can’t handle two requests at once thus throwing an error. The safest way to fix that would be to have all the code within the fiber-lambda but that limits you a little too much for extra functionality.July 25, 2017 at 1:52 am #9501the only issue is high amounts of traffic, it seems to crash under heavy load
I’ve not tried to use the communications features of Monkey2 yet but I’ve had a similar problem with BlitzMax where over saturating a connection will cause a problem. The solution as I recall was to limit client/server interactions (timing between packets) to 50-60 milliseconds per connected client. I was using UDP at the time but I suspect TCP would benefit form the delta throttling.
July 26, 2017 at 10:33 pm #9526Hmmm, yeah that makes sense, I’ve read that TCP has a form of error correction and a way of ensuring the packets get sent. I’ll see if I can make a small timer later and put the data inside of a Queue like structure.
This is really complex. x’D
 - 
		AuthorPosts
 
You must be logged in to reply to this topic.
