LÖVE

Do you have a handshake set?

I did not, derp. Thanks for pointing that out! - perhaps you should add to the .doc that the handshakes are absolutely necessary?
lots of thanks!

-end-

So after learning alot from my first attempt at a network based game i am now working on a concept-demo of another game...

Though one issue i struggle with is informing the client what id he is (clientid upon joining) - is there any way to get this id client side without having to send the id to the client upon connection?

Its not all that important, but it does clean up some code...

The clientid is completely server-side, and is not guaranteed to have any structure, it's just unique from any other clientid belonging to connected clients. Why do you need this? Maybe you could just have a counter and increment it every connect?

I track what clients have connected before by taking the IP (string sub out the port) of the client-id and storing it, also ALL the data regarding the client server side is stored in a table using the client-id as a key, this way i can rapidly track clients.

If i simply increment a id, then somewhere i need to track who this integer id represents, ofc i could use the integer as my key (from above table)
But seeing as its easier to prevent the same ip from connection twice this way i prefer the client id....

Also i need the client id as its what i use all over to reference the table that the server uses to store client data... such as any entities created belonging to that client, thus should i do a for loop and json encode a table containing each clients entity data using their clientid as keys and broadcast each client is quickly provided each others, and their own, entity data...

I only wished for a client side way as i atm need to send a message saying ("$AllocatedID$" .. json.encode(clientid)")
EVERYTHING client side, and then eventually server side, breaks should the client fail to get its id...

Its not too big a issue, but if connections are slow than i need to think of a few systems to prevent this or hope of a way for client-side id getting...
--i suppose a hacky method would to have the client create its own temp server, join it and then log the id -- deleting the server and continue ?

Once again, client ids are not guaranteed or specified to have any structure, and indeed they do not consist (at all) of ip:port pairs when using anything other than udp. The local server thing will most likely fail, too. Honestly, I can't see a reason why the client needs to know its specific clientid in the first place. (And why it can't use a value representing it.)

LUBE is only for LÖVE to LÖVE conncetions right?

-snip-

Is there a limit to how big a string can be when sending over the network?

I don't think there is one for tcp, and there probably isn't one for enet, but for udp it's 64k.