Leadwerks::Server connections

[GorzenDev]

i am creating a server for my game (mmo).

sending/receiving packets all work fine on a single client.

now i like to extend the server to accept multiple clients.

i have created a class called connections which holds all the info for a single client.

put a new connection in the list with peer info whenever a new succesfull connection is made with the server.

i then compare message->peer against connections.peer to read the messages from each client.

 

but now my question is what do you guys advice?

should i make a send/receive list for each connection to process the messages at a certain interval (connection thread maiby) ?

or is Leadwerks::Server smart enough to keep its own send/receive list ? and is this enough ?

 

[Crazycarpet]

Under the hood the Leadwerks networking system is ENet, nothing more... ENet provides great flow control as-is and you really shouldn't have a "channel" for each user. You (generally) should have a channel for reliable packets, and a channel for unreliable packets which LE's networking system uses ENet to create for you already. But really the channels you have created and what they're used for will vary hugely game-to-game.

Have a look at: http://enet.bespin.org/\

"Features and Architecture" is a good read.

You'll see that channels although they do not operate concurrently, will not hold up the sending/receiving of other channels if one channel is waiting or hanging on a reliable packet that hasn't arrived...

You'd be best off reading up on ENet and the features it provides and deciding what behavior would be best for your game as depending on the style of game (FPS, RTS, etc) you'll need drastically different networking setups for optimal performance.

Leadwerks::Server is as "smart" as an ENet host with a couple of channels (See the LE docs, one is reliable and sequenced, the other is just sequenced).

If you're using C++, shoot me a PM and I can help you with Leadwerks networking. I have a basecode that I can share that will help you with dealing with endianness, further aggregation, and a few other gotchas that come with the use of ENet.

[GorzenDev]

1 hour ago, Crazycarpet said:

Under the hood the Leadwerks networking system is ENet, nothing more... ENet provides great flow control as-is and you really shouldn't have a "channel" for each user. You (generally) should have a channel for reliable packets, and a channel for unreliable packets which LE's networking system uses ENet to create for you already. But really the channels you have created and what they're used for will vary hugely game-to-game.

Have a look at: http://enet.bespin.org/\

"Features and Architecture" is a good read.

You'll see that channels although they do not operate concurrently, will not hold up the sending/receiving of other channels if one channel is waiting or hanging on a reliable packet that hasn't arrived...

You'd be best off reading up on ENet and the features it provides and deciding what behavior would be best for your game as depending on the style of game (FPS, RTS, etc) you'll need drastically different networking setups for optimal performance.

Leadwerks::Server is as "smart" as an ENet host with a couple of channels (See the LE docs, one is reliable and sequenced, the other is just sequenced).

If you're using C++, shoot me a PM and I can help you with Leadwerks networking. I have a basecode that I can share that will help you with dealing with endianness, further aggregation, and a few other gotchas that come with the use of ENet.

thank you that whas an interesting read and it seems ENet is pretty robust on its own.
since all the server channels are sequenced i guess i could just process all received messages whenever they are received.
no use in me putting them in a list and process later then.

[GorzenDev]

i have another question about networking i hope you guys can answer.

is there some way to get an ip or some kind of id from a connection for stuff like banning accounts etc ??

i have been trying things like 

//prints a memory address i assume
System::Print("Address?: " + message->peer->driver->GetAddress(message->peer)); 
//get address info from peer ?
Address ip = message->peer->address;
//all print empty or 0
System::Print("Connection from: " + to_string(ip.host));
System::Print("name: " + ip.name);
System::Print("port: " + to_string(ip.port));

 

[Crazycarpet]

Well, when using ENet by default you'd simply access ENetPeers ENetAddress member and the 'host' value will always be unique as it's ENets internal representation of the clients IP address. I don't know exactly how Joshs version works as he hides the ENet usage behind lots of abstractions so he can simply make "NetworkDrivers" to switch between networking libraries in a clever way.

However I'd assume the fact that the addresses are returning 0 would suggest that a successful connection has not been established (as in ENet this would be the case.).

Are you POSITIVE you're even establishing a connection? with ENet/LE alike you'd do something like this to connect:

Client* client = Client::Create();
Peer* peer = client->Connect("someip", 1234);
// Now here we'd poll client->Update() til we receive a succesful connection message!
Message* message;
do {
	message = client->Update(); // Could do this better w/ timeout, etc.
}
while (message->id != Message::Connect);
// If we ever make it here a connection has been established since no timeout was specified.

If you ask me I think ENet does it better w/ their events xD

Like I said if you shoot me a PM I'd be glad to share a networking base I wrote for Leadwerks overtop of ENet that I think you'd find is much easier to use for you.... it allows you to write engine types and bytes directly, while also handling endianness for you and extending the aggregation of packets. It'd save you from all these headaches. (Oh, and it also handles sending/receiving on a thread for you, except for client connection.. this makes the client hang til they connect.)

[GorzenDev]

i am certain the client connects since the prints get done when  Message::Connect is received by the server,
after that i succesfully send receive and respond to a clientversion check so all is well in the form of connection and communication
its just that the address info of the peer returns empty.

[Crazycarpet]

That is very odd, I don't know enough about how Josh implemented this so this is probably a question he'd be able to answer. I'll send you the base and some documentation though, maybe you'll find it easier.