Planet Chili

Well that worked just fine . But another question i have asked about a winsock and server side , i mean i have heard that winsock is a bad choice for a a server side is it true ? i mean winsock works only for windows and some people say that better to keep your server on linux , do u have anything about this ? and if winsock is not the right choice what should i use for server side ?

I'm pretty sure what people meant by that is that Linux is just better for servers than Windows. There are really multiple reasons for why people choose Linux over Windows for their servers most of which relate to security but you can look that up yourself. In any case, you really should learn to use Linux if you ever think about managing your own server.

Honestly, I think network programming should be part of the basic curriculum and everyone should rent their own server for them to manage in the modern world(that and have knowledge on encryption of course). I already rented out one to create my own VPN with OpenVPN and use it as my own personal mail server. Now I'm trying to use it for my own cloud service to store my information and manage my devices like my security cameras and media players. Did your lessons on trigonometry help you to do stuff like that?

reductor wrote: Server::ListenForNewConnection can be adding a new item to the 'connections' vector which can move around the internal pointers within the vector. At the same time PacketSenderThread can be using the same pointer while iterating the vector. Not to mention all the other places where your using connections.

To simplify things and chances of race conditions you should have ClientHandlerThread take an argument for std::shared_ptr<Connection> (using std::thread), and it should stop using connection[id] as everytime this happens it should have the mutex. As you have a combination of read/write for connections you could use std::shared_mutex then just unique_lock for your writes/resizes and shared_ptr for any reads.

I think I see now what you are talking about - at least I was able to cause it to occur with the scenario where a client disconnects while another client is in the process of sending a message to their connection.

I'm a bit stuck on the correct way to approach this. On one hand, I could lock the connectionMgr mutex every time I append packets or send packets in any of the ClientHandlerThreads - but on the other hand this is not desirable since each individual client thread will only be able to append messages one at a time to the packet manager for any connection. Here is an image showing what I mean by this. What are your thoughts?



I saw what you put about passing in a shared ptr to the connection to the thread, but the part that i'm worried about is iterating through the rest of the connections should something happen to them (disconnect for example) in the middle of a for loop iteration where we are appending to their packet manager. (Ex. Client 0 sends a message and we have to iterate through Connections 1-4 to send the messages out to them - How should we go about iterating through these safely other than locking the connectionMgr mutex every time?)

To save explaining my vision of what is required to remove some of your threading issues, I have put the work required up on

https://github.com/ReDucTor/network-tut ... its/master

This is still not completely thread safe as 'Connection' is still used over multiple threads. There is some room for further performance improvements within things like PacketSenderThread that can do a copy of the list with the lock, then use that copy without the lock to avoid holding onto the lock for longer. (Same with the message packet type)

P.S. Feel free to jump on discord if you want to talk about it easier then back and forth over the forum.

reductor wrote:To save explaining my vision of what is required to remove some of your threading issues, I have put the work required up on

https://github.com/ReDucTor/network-tut ... its/master

This is still not completely thread safe as 'Connection' is still used over multiple threads. There is some room for further performance improvements within things like PacketSenderThread that can do a copy of the list with the lock, then use that copy without the lock to avoid holding onto the lock for longer. (Same with the message packet type)

P.S. Feel free to jump on discord if you want to talk about it easier then back and forth over the forum.

I actually was not aware of the existence of shared_mutex or else I would have resorted to using that initially.

Thank you so much for that. I'm still reviewing all of the changes you had made.

Hello guys have a question about Tutorial NO.8
Server Side : Client side :
both are same server and client side . as far as HOST i understand that its a host or server and network is pc witch client are on so .When server send and receive data its makes sense When sending convert from host to network, and when receive you convert from network to host .
But this is the same inside Client and this makes no sense to me because if you are on client and you sending data to server you should send from Network to HOST and receive from Host To network or do not convert at all cuz server side will convert data before sending to client so you dont have to worry about when receiving or sending data cuz server will convert all data.
Let say i am sending and int from server to client :
SO first i will convert int Host to network order , and once client receive that data it already by network order so why do you converting from host to network again ?

egizz983 wrote:Hello guys have a question about Tutorial NO.8
Server Side :

Code: Select all

bool Server::SendInt(int id, int _int){
_int = htonl(_int);//Host to network
}

bool Server::RecvInt(int id,int _int){
_int = ntohl(_int); // Network to host
}

Client side :

Code: Select all

bool Client::SendInt(int id, int _int){
_int = htonl(_int);//Host to network
}

bool Client::RecvInt(int id,int _int){
_int = ntohl(_int); // Network to host
}

both are same server and client side . as far as HOST i understand that its a host or server and network is pc witch client are on so .When server send and receive data its makes sense When sending convert from host to network, and when receive you convert from network to host .
But this is the same inside Client and this makes no sense to me because if you are on client and you sending data to server you should send from Network to HOST and receive from Host To network or do not convert at all cuz server side will convert data before sending to client so you dont have to worry about when receiving or sending data cuz server will convert all data.
Let say i am sending and int from server to client :
SO first i will convert int Host to network order , and once client receive that data it already by network order so why do you converting from host to network again ?

So maybe I wasn't clear in the video about what is going on here.

hton (Host to Network) will convert your integer into Big Endian. Just because you are running your server program on a computer, we do not know if that computer is big endian or little endian. To compensate for this, we always send the integers in big endian format so we know how the data is formatted.

ntoh (Network to Host) will convert your integer from Big Endian to the computer's endianness. If I am on a big endian computer, these functions do nothing. If I am on a little endian computer like most intel processors, then the ntoh will convert the Big Endian integer to little endian so that I can read it properly.

Does this make any more sense?

Uploaded Tutorial 13. Sorry about the wait. Also the tutorial is pretty unorganized, but I was just trying to cover a lot of changes that I had made to the solutions. Feel free to ask any questions that you may be confused about regarding the solution code.

Not making anymore blocking tutorials, want to start on nonblocking sockets next.

Uploaded tutorial 1 for the nonblocking series

Uploaded tutorial 2 for the nonblocking series