Client Connect Loop and Port Option

[lsri2]

Hi, would it be possible to add a client connect loop similar to VoidSW and NetDuke32 whereby the client simply waits for the host. As it stands now, the host has to be ready before the client tries to connect.

Also, can you add a -clientport command-line option for the client to specify their own port to be used when connecting to the host.

[tmyqlfpir]

I'll investigate later today, thanks!

[lsri2]

Thanks. The real key is the -clientport option, as the first case can always be worked around with launch delays for the client.

[tmyqlfpir]

Sorry for the delay. I've fixed the currently existing command line port argument, and have added a new argument for retrying a client connection via netretry.

If these work and are to your specification, please close the issue. Thanks!

[lsri2]

Hi, are you saying the same -port command can be used for specifying both the server's port to connect to and client's port to connect from.

[tmyqlfpir]

Yes.

[lsri2]

Hi, could you tell me the usage for a client, can you use the :port now like

-client ip:serverport -port mylocalport

[tmyqlfpir]

An example would be -client 127.0.0.1 -port 1234

[lsri2]

Ok, but normally that specifies the servers port. How do you specify both the client's local port and the server's port? That's the key.

[tmyqlfpir]

The port command should be setting the port for both client and server usage. If it isn't then that is a bug.

[lsri2]

Hmmm, sorry to keep pestering you about it. Basically, for example, if the server is using port 8000 and the client is using port 8001, how would you connect to the server at port 8000 using port 8001?

[tmyqlfpir]

Oh! I don't think that can be done without decoupling a lot of the connection code, which is more of an upstream PR. Both the client and the server have to be on the same port.

[lsri2]

Ah, ok. Well the -netretry works . The -port doesn't do anything for the client's local port from what I can tell, it simply specifies the server's port like before. But, if they can't be independently specified, that makes the most sense still.

[tmyqlfpir]

That is more of an upstream PR as it involves rewriting the current enet implementation for client connection within NBlood. Thanks for testing.

[lsri2]

Thanks!

[lsri2]

Sorry to reopen, I was thinking about this more. I just want to be sure we're thinking the same thing. I am looking for a way to set the clients local binding port. As it stands now, it simply picks one for you, so it's basically random on each connection. I looked at the code and it appears all you would need to change is this code for the client from

gNetENetClient = enet_host_create(NULL, 1, BLOOD_ENET_CHANNEL_MAX, 0, 0);

to something like

gNetENetAddress.host = ENET_HOST_ANY;
gNetENetAddress.port = gNetClientPort;
gNetENetClient = enet_host_create(&gNetENetAddress, 1, BLOOD_ENET_CHANNEL_MAX, 0, 0);

[tmyqlfpir]

/** Creates a host for communicating to peers.
 *
 *  @param address   the address at which other peers may connect to this host.  If NULL, then no peers may connect to the host.
 *  @param peerCount the maximum number of peers that should be allocated for the host.
 *  @param channelLimit the maximum number of channels allowed; if 0, then this is equivalent to ENET_PROTOCOL_MAXIMUM_CHANNEL_COUNT
 *  @param incomingBandwidth downstream bandwidth of the host in bytes/second; if 0, ENet will assume unlimited bandwidth.
 *  @param outgoingBandwidth upstream bandwidth of the host in bytes/second; if 0, ENet will assume unlimited bandwidth.
 *
 *  @returns the host on success and NULL on failure
 *
 *  @remarks ENet will strategically drop packets on specific sides of a connection between hosts
 *  to ensure the host's bandwidth is not overwhelmed.  The bandwidth parameters also determine
 *  the window size of a connection which limits the amount of reliable packets that may be in transit
 *  at any given time.
 */
ENetHost * enet_host_create(ENetAddress *address, size_t peerCount, size_t channelLimit, enet_uint32 incomingBandwidth, enet_uint32 outgoingBandwidth) {

The usage of NULL seems intentional according to the documentation, regardless I've pushed an commit to allow specifying a local port via -clientport. Try it out when it has finished compiling.

[lsri2]

Works great. You're the man, man.