Successful TCP Client/Server Separation

Home Forums Monkey 2 Code Library Successful TCP Client/Server Separation

Tagged: ,

This topic contains 2 replies, has 2 voices, and was last updated by  scurty 17 hours, 58 minutes ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #9263

    scurty
    Participant

    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.04

    Please 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.

    Attachments:
    You must be logged in to view attached files.
    #9501

    Richard Betson
    Participant

    the 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.

    #9526

    scurty
    Participant

    Hmmm, 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

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.