For any such networking problems, use Wireshark or similar to capture the network packets. What was actually sent over the network?
9 minutes ago, jt.tarigan said:
I'm currently developing a client C# (Unity) based application communicating with a C based server.
When developing a new protocol, I would recommend sticking to one language until you are completely sure the protocol part works (remember protocol, not entire program. For an existing protocol, say HTTP, test against known good client/server programs). It is also a great example of code where pretty much every line should have automated testing because small mistakes are easy and networking has tonnes of edge cases and problems to solve.
One of the big ones is that TCP is not a message based protocol, and Write/send and Read/recv may not get as many bytes as you expected, may send part of the data, one send() might get split into multiple recv(), even in really annoying ways like splitting a 16bit number in half, or ASCII delimiters like `\r\n` and `\r\n\r\n` (HTTP for example). Always check the return values, never assume it actually sent all of `outStream` or that `recvbuf` got all of it.
8 minutes ago, jt.tarigan said:
However, when I print the received char (in the first index of the array) by using a simple std::cout, it always print "=" instead of whatever character I send from the client.
Either your not sending the right thing, or you messed up your C buffer management and '=' happens to be lying around in memory.
11 minutes ago, jt.tarigan said:
13 minutes ago, jt.tarigan said:
strncpy_s(recvbuf, messageObject.messageBuffer, result);
You using C or C++? `strncpy_s` takes 4 parameters, and you don't appear to be checking the return value, so not sure what that is doing. There is very very little benefit to manual string stuff in C++. Also pretty sure `strncpy_s` is the wrong choice here, if I am doing manual buffer management, it is nearly always `memcpy`, and `memmove`, after all to use `send` and `recv` I had to know the lengths anyway.