Skip to main content
GameDev.net gamedev.net
🔒 Locked

Questions on Enet's window logic

Started by Drew_Benton Apr 6, 2009 at 5:58 AM 0 replies 1.9k views
Original Post
Drew_Benton
Drew_Benton
I'm in the process of learning Enet for use in my other project. I am working on updating the core code to be C++ and a more OOish architecture. I'm also removing a few numerical limits inherent in the design (from smaller sized data types). I eventually plan to drop in my IOCP code for even more fun using UDP on Win32. Right now I'm trying to understand some of the reliable/unsequenced window logic used in the library. I'm having a hard time understanding these constants and the associated logic and how it affects the network code. I've done some reading up on the Sliding Window Protocol as that is what is being implemented here, more or less, but I'm still a little confused. Q1. For the constant: ENET_PEER_FREE_RELIABLE_WINDOWS = 8, how do you obtain this number? Is it always 1/2 of ENET_PEER_RELIABLE_WINDOWS = 16 or is it based on other constant (such as 1/4 of ENET_PEER_FREE_UNSEQUENCED_WINDOWS = 32)? What is this value for, I am thinking it is how many outstanding windows can be in use at a time, but I'm not sure. Q2. Looking at the enet_protocol_send_reliable_outgoing_commands function, line 1200, there is a huge chunk of logic I'd like to simplify, but I don't quite understand the idea of the code.

while(currentCommand != peer->outgoingReliableCommands.end())
	{
		outgoingCommand = (ENetOutgoingCommand *) currentCommand;

		channel = outgoingCommand->command.header.channelID < peer->channelCount ? &peer->channels[outgoingCommand->command.header.channelID] : NULL;
		reliableWindow = outgoingCommand->reliableSequenceNumber / ENET_PEER_RELIABLE_WINDOW_SIZE;
		if(channel != NULL && 
			outgoingCommand->sendAttempts < 1 && 
			!(outgoingCommand->reliableSequenceNumber % ENET_PEER_RELIABLE_WINDOW_SIZE) &&
			(channel->reliableWindows[(reliableWindow + ENET_PEER_RELIABLE_WINDOWS - 1) % ENET_PEER_RELIABLE_WINDOWS] >= ENET_PEER_RELIABLE_WINDOW_SIZE ||
			channel->usedReliableWindows &((((1 << ENET_PEER_FREE_RELIABLE_WINDOWS) - 1) << reliableWindow) | 
			(((1 << ENET_PEER_FREE_RELIABLE_WINDOWS) - 1) >>(ENET_PEER_RELIABLE_WINDOW_SIZE - reliableWindow)))))
			break;

		commandSize = commandSizes[outgoingCommand->command.header.command & ENET_PROTOCOL_COMMAND_MASK];
		if(command >= &host->commands[sizeof(host->commands) / sizeof(ENetProtocol)] ||
			buffer + 1 >= &host->buffers[sizeof(host->buffers) / sizeof(ENetBuffer)] ||
			peer->mtu - host->packetSize < commandSize)
		{
			host->continueSending = 1;          
			break;
		}
//... removed ...




Any help there? [lol] I was hoping to either simplify that or take quotes from Wikipedia to post as comments as to what is going on. Q3. ENET_PEER_UNSEQUENCED_WINDOWS = 64 is not actually used anywhere in the code and likewise is not found to on any Google search results. Should this value have been used and indicates a bug or was it just not ever needed (if anyone knows). Thanks!
hplus0603
hplus0603
That block of logic seems to test something like "If I'm about to send the first packet in a new window, and that window is greater than what I'm currently allowed to extend, then don't."
enum Bool { True, False, FileNotFound };

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.