@sudu

Devlog 6:

HOWDYY EVERYONE!! i know its been an eternity since ive logged in to stardance, and trust me i have a very good reason for this. Firstly, yeah i was busy with my college admissions stuff, quite a long time honestly (and its just the beginning). But also during this time, i was hard at work pushing this project forward for the actual file transfer protocol thing. It was NOT at all easy as i was thinking. To send a file, both the users should have a prompt that shows what type of file they’re receiving and then ask them if they would wanna accept it or not. it seems VERY easy but trust me its the opposite. It took me like a week to come up with a very good and redundant method to ask the users. What is hard you might ask? Well the thing is, you need to have a seperate message parser (ie serializer) so you can make out the file details such as the file name, file size, etc. You need to send that seperately, and then ask the recv thread (the one that is always running to see if there are messages on the socket–multi-threading baby!) that the next incoming packet should be a file negotiation packet (as the name suggests, it negotiates with the user if they wanna accept the file) and then assigns the send thread to pay attention for the user command to accept (using “/accept” or “/reject”) for the files. As for selecting the files, im using an API called “tinyFD”. It’s goated honestly. Made my work a lot easier. Basically what it does is it opens the file saving / file opening dialog native to you OS or display server! Pretty darn good for cross-platform project like this (tho my project only works for unix atm).

This was about the file transfer stuff. But there are also many architectural improvements that I made throughout to improve the readibility of the code. For example, instead of endless nested if-else statements, i used switch statements. For the commands, i made a seperate command parser (tho its buggy, not my main focus for now, but yeah working towards it).

A few days ago, a reviewer (huge thank you!) asked me for a feature for custom ports. I’ve added it. Now, you should select a port on which you want your host/server to listen on. Took me long enough, but yep, working like a charm. Another issue i found on the reviewer’s screen rec video was that the server STILL proceeded to operate if the binding failed (for context they had port 8000 – the default port for this project previously already busy. When they attempted to run the server, the socket binding failed due to the port being used by another entity). The server would still go to its operating mode. Thats not good and meaningless. So fixed that bug as well. Thank you, reviewer for taking time having a look on my project!

Anyways, thank you for reading, have a great day!

Devlog 5:
Gm! So today i started off with documenting the architecture and the protocol design for WireSend. Have a look below!

Devlog 4:
HELLLOOO omg ive been out so long. These past couple of days ive been thinking so long about protocol design for the actual file transfer that i said im working on. GOsh it was such a long journey. 5 rejected ideas and endless staring at the whiteboard. Nevertheless, ive managed to build a file negotiation system (so that the other device can accept/reject the incoming file) that can then also transfer files later on. The reason it was so complex because well, file negotiation is completely different from normal message packets. I need to measure the file size (that can be 64-bit worth in size….which is just BIG), the file name size (which was the big issue for me) and bundle them together and send over the wire. Earlier i was thinking to make completely different packet type for such tasks, but that was seriously wrong idea as i would end up with endless conditional loops, and it looks awful. Instead what im doing is im serializing all that info and shoving it inside the body of the main packet. Then build a seperate deserializer for the file metadata so it could extract data and show it to the user. You could say i could’ve just used the existing messaging infra to transfer the info…after all they’re just strings, right? Well, true they’re just strings, but we’re handling them completely differently. For instance, we’re building a separate architecture for this so that the messaging thing remains different from the file thing. They both dont have any business to be together. That’s called modularity. And besides, i will be transferring files…i certainly couldnt do that using messaging technique and was bound to make a different protocol. SO here i am. Im so sleep deprived rn. so good night

Devlog 3:
Hey y’all new day new ambitions, at least i dont have them. Jokes apart, today I implemented something which bridges the gap more towards the actual file transfer. I added the binary to ASCII and vice versa conversion for receiving and sending packets respectively. Earlier to keep things simple, I was just sending std::string packets, but files cannot be sent that way. Thats one of the foundational stepping stone for this. Apart from this, I also improved the readability for the enum values for payload_type (for which I was kinda responsible in the first place lol). I used to start the numbers with 0…examples: 010, 002, etc. They all represent octal values in C++. I didnt wanna get into that mess so I just removed it. I also added a necessary check to see if the receiving packet contains text or a file chunk (tho only text for now since Ive not implemented the file transfer yet). Im yet to do that flag for the sending as well, but not before I add file handling.

Nowadays, I’m just changing the architecture rather than functionality and features. Since I made this project for file transfer than chatting, I think I’d keep both of them, because I have one of them ready, and why not?

Thanks have a great day!

Devlog 2:
Added the SendPacket() function to both client and server module. Im essentially making custom functions so I get better flexibility with managing my packets rather to directly use unix functions to do what I want. I really needed the pointer arithmetic check (this is common for the ReceivePacket() as well) because well, TCP guarantees all the bytes will be sent, but not the time it will take to do so. That is why we have to keep looping through our buffer size to get an idea of how many bytes we received and how many are remaining. Yep, its subtle but absolutely important for file transfers. You dont want receiving incomplete and corrupt files!

Devlog 1:
soooooooooooo i finally understood what einstein type shi brain I used before my vacation. Right now my main goal was to not add new features, but to improve the readability of the code. For this, I made a new function, ReceivePacket(), that does nothing but uses TCP streams to receive packets. Earlier I repeated its function for like 4 times, so I made a dedicated function in my API so I could easily use it and reduces lines of code. Enough tech talk, im still recovering from the vacation mode haha.

As i started this project wayyy earlier than i logged into hacktime, I have the chatting thing ready. Though its not much, its better than nothing. Atleast the foundation is set up. I was going to add the file transfer stuff soon, but I went for a vacation for like a week and I forgot much of the stuff (my memory is like a gold fish). But the one thing that I did learn was that: ALWAYS DOCUMENT AND ADD COMMENTS TO YOUR CODE. That way reading it after an eternity is much more sane. Anyways, what I did really was read the code. Spent two days understanding what my sleep-deprived brain at 2AM thought. Wish me luck. b-bye! (also idk what to upload in the screenshot when i said i did nothing meaningful)