How to Write a Socket Server from Start to Finish!

[@GregTash]

this channel is a hidden gem

[@hoff._world]

yeah you have to mine below layer 16 around y -53 it seems

[@CYBERNETIC-ANGEL]

so glad i discovered this channel

[@thehady1]

I'll always wonder how and where you learn to be this great.i really admire you and look up to you !great video btw

[@MateoEstudiante]

Hey. Your content is gold! Thanks for sharing. Hoping you the best.

[@Blue-bb9ro]

Love your channel, learning so much. Thank you.

[@gmeister3022]

The GOAT is back

[@hoff._world]

what can I say ur boy loves to cook

[@juststudying1019]

Thanks your channel is amazin, please keep uploading videos like this. They are very usefull.

[@hoff._world]

dont sweat it chief will keep em coming :)

[@mangeshshikrodkar6192]

just amazing

[@mblenczewski]

Nice video! With your locking, it seems that reads are more likely than writes (when walking the watch entry table, for example). Why not use `pthread_rwlock_t` instead of `pthread_mutex_t`, to avoid some unnecessary lock contention in the common case of reading? Also, in your makefile, why not use `cc` instead of `gcc`, to have builds "Just Work" on systems where gcc isn't installed by default. Finally, I appreciate that these videos are already very long, and must take at absolute minimum twice that to edit together and publish. They are well put together. Would it at all be possible in future to spend some more time working through the architecture and dataflow? Perhaps on a virtual whiteboard or in a paint program? I ask as I found myself rather lost with how you manage connection state (pointers into the watch table for publishers/rolexhound, and no state for subscribers?), even after rewatching the architecture segment and attempting to look over the code. It should be very simple, and I can convince myself of this when coming up with my own solution to the problem, but there is just something I am missing with your solution.

[@hoff._world]

hey thanks 1. yep you totally could, and I did consider it but ultimately couldn't be bothered to think about all the situations where I'd only be reading or writing and applying the appropriate lock. Definitely a valid substitute for a full mutex tho. 2. ye fair but tbh I kind of expect people to do up their own makefiles I just include mine as an example, if someone cant figure out how to change the C compiler in it then they should take a step back before doing this project for example :D 3. I'd really like to and in fact I had done theory videos before but they generally get the comments filled with people asking for the implementation :D I'm gonna be trying a bunch of stuff out over the coming weeks and will get a better idea of what people wanna see, cheers for the thoughts 4. Yep I agree I didn't really explain that bit so well. It's easy if you have the context loaded in your head to sometimes skip explaining things that may not be obvious to someone fresh: Basically I didn't want 2 tables (for complexity/video length reasons) so instead of keeping track of rolexhound instances separately to smartwatch subscriptions he will initialise himself onto the sub table with a NULL watchPath and non-NULL activeFiles. Our table scan function can see who is a rolexhound by matching those parameters. It can also find a 'free' spot on the table for a new subscription by finding an entry where watchPath is NULL and so is activeFiles. A smartwatch subscription entry will have a non-NULL watchPath, a non-NULL activeFiles and a non-0 sub and pubFd. Hope that clears it up :)

[@mblenczewski]

​@@hoff._worldYes, thank you very much for the clarification, and again, good video. Looking forward to the next ones :)

[@benhetland576]

The mutex juggling was what I felt most uncomfortable with, especially within the loops where there are break/continue/return to jump past a matching pair of lock--unlock. There is no longer only the two calls with a guaranteed execution path crossing both of them every time, or at least it is very difficult to assertain so when reading the code. After leaving such a loop there is a situation that sometimes a lock is held, and sometimes not. That is a recipe for writing a bug, especially within all that logic with if-statements, which is known to be maybe the most common cause of programming errors! Deadlocks be waiting to strike one dark night...

[@mblenczewski]

​​@@benhetland576 Completely agree, that code is quite hairy. I would have personally tried to factor the shared table access into separate, smaller helper functions to help guarantee correctness. With this approach of splitting both publishers and subscribers across multiple threads, I don't naively see a way to avoid the locking, without either moving to more complex lock-free datastructures (which i am not knowledgeable enough in), or by moving from shared data to a sharded approach (at the cost of reduced functionality; watches no longer cross the thread/shard boundary). Currently trying to implement my own version of this server as well, to see what problems there are to solve. After all, I can't just sit here critiquing code without putting some action behind my words :)

[@hoff._world]

@benhetland576 I have tried to be careful with my un/locking positioning despite that, but as you say time will tell :D

[@Palatonista]

The man is cookin

[@hoff._world]

KDE Plasma 6 just dropped, so I may do a setup video once I get it all installed :)

[@Palatonista]

@@hoff._world POG

[@illegalsmirf]

BASED gigachad 💪🤓

[@bakhtyarsayed]

How does he keep making bangers???

[@hoff._world]

just 👏 🔥 built different 💯 💯 👌

[@Shxvang]

very kool

[@benhetland576]

28:40 It is pretty useless to call that _watch_entry_factory_ before returning. You will only affect the local copy of the struct, which you will not use afterwards anyway. Actually the whole way you pass that _matchEntry_ parameter is pretty dangerous! The struct will be copied, which includes the pointers it contains. There's no fancy copy constructor in C to manage the pointer members, like you could have in C++, so you have duplicate ptrs to the same string memories. Should you have called the _reset_ function instead you would have a double-free later on. Now, you called the _factory,_ which luckily avoids calling _free_ (no need to test for NULL btw), so you avoid the double-free at the risk of leaking memory instead, but it is totally pointless since the variable goes out of scope immediately afterwards. ;-)

[@hoff._world]

Hmm I should have passed the pointer of the match entry struct since my intention was to pass by reference, missed that thanks. Given that context the rest of the logic for resetting it is correct.

[@benhetland576]

@@hoff._world Bingo! Yes, even a const ptr maybe. That's both the good and the awkward thing about C -- we have to be explicit about everything and every nitty gritty detail. Let the caller have all the responsibility for that struct, including resets if needed.

[@benhetland576]

@@hoff._world Otherwise you have made quite an elaborate video there, man! Even after the shortcuts with memory handling. Nice work!

[@BoBo-nv9qu]

Useful video.

[@hoff._world]

thanks xx

[@ACium.]

which editor is this?

[@hoff._world]

it do be Kate