therealredriver559 / asyncio-tcp Goto Github PK

Needs to be documented badly. I will do when I have time. Or when someone else comes along

The chat history is currently being sent all at once, which is a terrible idea. It's like this for the moment until a new solution is implemented.

TODO

• Finish the channel creation menu
• Finish the chanel join menu
• Add the user context menu
• Add auto slash command arguments when typing and an option in settings to disable it

not sure how I over looked this. When a new user joins all the messages say they arrived / were sent at that time. I would have to store messages and the time sent in a database to fix this issue. I would also have to know the local users time. Can be done from using their IP address but its not really a priority at the moment

This file had a few clauses and edge cases where certain commands and things did not work. I need to add test cases to prevent things like this from happening

A great feature would be to add some sort of message control feature. At the moment, the Server only has 1 single point where it can listen to messages, if the server were to ask for something from a command such as more information or a password (Future private channels feature) then it would need some sort of way to accept that data. What I plan to do is add some sort of variable where I can specify what process has control over the network with receiving. Things such as the heartbeat / ping system would not be affected, but this would be a lot more useful. I'm still not sure of how to make this feature yet, so I am posting the issue / wanted feature anyways in case someone comes along with any sort of interjection or suggestion that they have.

The color checking system in the client.py file uses .startswith(username) to check and see if the user receiving the message is the same one that sent it. The only issue with this is having almost identical names or with a slight difference at one end. For example lets say we have 2 users. Test1 and Test. If Test1 were to send a message the .startswith(username) would verify that it started with the other persons partial name giving a false positive. This only happens when the person with the shorter name or the parent name sends a message. So for I've thought about sending the information from the server as this format ('00:00:Username Message') Ill be sending the username length and the message length so I can index it from the client.py file. This would give me the username and checks if the message is blank, I'm sure its not the greatest idea but any suggestions or ideas are awesome.

This is an unknown silent error currently. If a client is logged in and swaps their wifi connection, by using a VPN, proxy, or just a turning off and on their wifi it will cause some sort of error. The client side shows the exception but the server does not. Some how the client is not being removed from the clients list in Temp.py when this happens and is capable of storing a "n" number of un used or blocked usernames that you cant log back in with.

When writing to the log file, there can be an issue where something might try and read while also be writing. There might have to be some sort of lock implemented to make sure it doesn't happen.

Same issue with gathering the clients from client.values()
A new user may join or leave when trying to gather this data. I could just make a copy and use that data but I'm not entirely sure on the efficiency and other workarounds.

At the moment certain files are mostly async, while others have it, but under large stress loads this fails. Im looking Into queues for all processes such as messages, logs and general server operations to prevent it from being overloaded wirh data.