Is NetworkTransport.Connect(...) a blocking function ???

Hello All

I am hoping somebody can answer this question because its doing my head in LOL

I am writing my own TCP Network Library (external from Unity) which uses threads which works great so far, but I wanted to simplify how to use it, a bit like how NetworkTransport works.

I have always used Event Callbacks within threads, granted Unity cries when you use threads but I have always found ways round that.

But I notice that NetworkTransport.Connect(...) returns the clients Connection ID and its called within the main thread, I managed to get my code to do the same, but when I delay the network message being sent back from the server to the client with the clients connection id the whole app hangs (i.e. the function is in blocking mode)

So I was wondering would NetworkTransport.Connect suffer the same issue if the server was lagged out between the connect and sending back the info parts. Or maybe the network message with the connection ID in it was delayed for a few seconds or lost.

Because where its run on the main thread and the function only returns when it has the clients connection id, it must also be a blocking function i.e. a form of while loop in there to loop until it has the required information.

Or am I missing something silly here?

Regards

Paul

 

The client connection Id from the Connect function is only local.

The server connection id is provided with a connect event :

NetworkEventType evnt = NetworkTransport.Receive(out outHostId, out outConnectionId, out outChannelId, buffer, bufferSize, out receiveSize, out error);

 

As far as I am aware the clients ConnectionID is returned from the Connect function shown below:

Code (csharp):

1. int connectionId = NetworkTransport.Connect(hostId, "10.0.0.42", 54321, 0, out error);

Shown here: https://docs.unity3d.com/ScriptReference/Networking.NetworkTransport.Connect.html

But then again the docs have never been clear have they.

I will do a very basic set of code to test this and get back, TBH I really should of done this in the first place, but it does make sense on what you are saying, TBH I would do it the exact same way if I was writing a Network Library.

Like I said I will get back.

Paul

 

I think you are trying to treat the connectionID as some global unique identifier that all connected clients can see, where its actually just some local data for only you to use locally. If you want some unique ID for all connected players to know what player is who, you will need to do that yourself.

In other words, on your client you could see player1 connectionID be 1 and player2 connectionID be 2, where as player2 might see player1 connectionID be 3 and your connectionID be 7. Its all local and depends on the order you connected to them I think.

So when you call the NetworkTransport.Connect method, it gives you the connectionID right away that it will assign for that connection since its only really locally used, so no need to wait for the other side.
So no, I dont think its a blocking function.

 

Well I thought it would tell the client its connection id so that when that client sent a network message it included the id.
But it seems that the client never knows its connection id to the server, so this must be all done behind the scenes in the actual NetworkTransport code due to I know I can see the server sending it to the clients when I sniff the network packets.

I was working on my own Client <--> Server setup using multiple threads not a P2P one, so the clients won't see any other clients connect or disconnect unless I have the Server send that information.
And where I only was testing with one client and it returned 1 I assumed that was the clients connection ID on the server, which I now know its not.

So the client will always see hostId of 0 and connectionId of 1 when the server sends the client a message.
Where hostId is an ID to reference the LocalEndpoint and connectionId is an ID to reference the RemoteEndpoint

As for it being a blocking function, I now totally agree with you.
It was where I was thinking it was returning the actual connection ID on the server which its not.

So I will go back to my older code before I changed it, so I will have my Network Library have the Server send to the client when they connect to it a network message stating its connection ID.
And have the connect function return right away and have the client network code in my library receive that internally.
Which I am certain the NetworkTransport is doing internally behind the scenes.

Thanks for the replies, I now know how I will be doing my Network Library, which I am now relieved due to I am not a fan of blocking code to wait for an outcome.

Regards

Paul