koobas.hobune.stream
TcpClient not working when building,
Hello!
I am working on a vr game for Windows where I need to connect to another program using TCP. Right now TcpClient is used and works great when run from the editor, however when building the project the game wont accept the connection.
The prodject uses .net 4.x
The code that I use:
TcpListener listener = new TcpListener(IPAddress.Any, 8911);
listener.Start();
TcpClient client = server.AcceptTcpClient();
NetworkStream ns = client.GetStream();
ns.ReadTimeout = 60000;
while (ns.CanRead)
{
byte[] msg = new byte[64];
try
{
if (ns.Read(msg, 0, msg.Length) > 0)
{
//Use the data
}
}
catch
{
}
}
Thanks in advance!
,
There are several thing not quite clear. Do you run that code in a seperate thread? Do you actually gracefully close the connection and also make sure your thread terminates? If not user started threads can live on even when you stop playmode in the editor. If that's the case your port would still be blocked.
Next thing is TCP is a streaming protocol. So there might be several reads necessary to receive all the data. TCP is not message based unless you build your own application layer protocol on top of TCP.
Another thing that is often overlooked is the runInBackground setting. If that is not set to true, the Unity application will not update when it doesn't have the focus.
Thanks for the response @Bunny83
I don't think that several reads should be neccisary beacuse of the packets that i am sending.
The code runs in a separate thread using:
SocketThread = new System.Threading.Thread(networkCode);
SocketThread.IsBackground = true;
SocketThread.Start();
and the RunInBackground player setting is turned on.
All of the objects are freed and the problem exists after a reboot so I don't think it is a thread that is still open.
I wonder if it is beacuse the project is using VR?
Well, first off, TCP is not a packet based protocol. It's an endless strea$$anonymous$$g protocol. The stream is transmitted through packets but those can be fragmented in any way. So it's perfectly possible to only receive a part of your data. Also if you send multiple "packets" you might "read" one and a half of your packets in one go. If you want to send messages / packets over TCP, you have to take care of seperating out your message from the endless stream. Since we don't see any of your data handling we can't really help you on this one.
I don't think that using VR has any effect on this. $$anonymous$$y guess is simply that you might have messed up your network code somewhere.
Recently I made a small example for the answer on this question where I had a standalone TCP server that is sending out images. The application layer protocol is extremely simple since it only sends a 4 byte header with the size of the file / frame followed by the actual file data. I've build the client and ran 4 of them in parallel and all received the data pretty well. I also increased the send rate to about 10 images / sec and it ran pretty well.
Note that I used the BinaryReader directly on the network stream. This has the advantage that any Read call on the reader will block until enough data has arrived. That way we don't have to worry when only partial data has arrived. It's just important that your application layer protocol can actually identify your "message" in that endless stream of data.
