So how many of you know raw socket programming?

You are either a girl or retarded or both.
kys

You kys

It's a phase, you'll grow out of it. I cringe coming across my code comments when I was a teen.

Did some time ago. Wasn't that hard, but you had to use the man A LOT.

Why do this? They're defined as int which isn't guaranteed to be the same as int32_t.
Unfortunate.
This is pretty abusive and relies on workarounds in Linux kicking in for people that wrote shit code like this in the '90s and earlier. It /should/ fail ever since the introduction of SCTP as it also provides SOCK_STREAM. Linux gives special preference to TCP, UDP, and ICMP to coax code like yours into working.
Don't use this, it's been effectively deprecated since the late '90s. getaddrinfo is the modern way that works right for IPv6 and doesn't have re-entrant problems or portability problems.
>sometimes checks == -1, sometimes < 0
Why? It makes me suspect some of this is copy paste.
It might not matter in your code right now but you should always do it anyway to avoid problems later.

Using C for any new network-based program is silly. Try Go.

off your self

...

Maybe you're actually this clueless so I'll explain. GC requires pauses. Consumer-level networking hardware has tens of microseconds between packets (and of course it only gets faster from there). Go's "wow, we're so low latency and 'pause-free'!" GC pauses for tens of milliseconds in the best of cases. There's a factor of 1000 difference, there. No one would be so stupid as to write heavy networking code in Go, except for buffered protocols for things where latency doesn't matter (webshit). And so no one does.

Did you use any guides in learning socket programming? Is there anything that you would consider an essential resource?

I started with Stevens' book and the rest was just learning by doing. It should be very easy today as there is so much information available and really amazing tools.

can we ban meme posts like these already

Awww, did he hurt your feelings by pointing out the truth?

just fuck my shit up fam :^)

I work on a game

Wow, they couldn't even copy sendto correctly.

I did once in python well, boo but I just don't have the need at the moment.

Just use a constant bitrate stream and send random (encripted) data when your not using it for your pizza. It's really not that hard. Just takes bandwidth so make sure you got'st no caps.

It requires extreme cover traffic and/or extreme latency and is why I said solutions that really do solve the problem are not ones anyone would want to actually use.

code does not use IPv6 sockets
K
Y
S

Thank you

I was the guy who wrote the ultra buggy tinyirc, and I'm currently attempting to rewrite it in rust, but rust doesn't have non-blocking sockets.

So at least they got one thing right.

github.com/carllerche/mio

The garbage collection is there because concurrency with manual memory management was found to be a good alternative to suicide.

t. The Go Programming Language, p. xiii

I saw this library, but I'd rather use the sockets in the stdlib. I found a semi-hacky way to set the timeout really low, so I can do it without non-blocking sockets.

Nah, just shit code of my CS 1st year. Should delete it in shame but I'm too lazy to do a real cleaning.

You're nuts. Blocking operations are a failed paradigm.

I'd take painful over useless. Pausing is a non-starter.

talks.golang.org/2015/go-gc.pdf
With 1.5 it seems like the speed is much better for GC.

Their "much better" is around 10ms which I used as my 1000x too slow for networking example. GC will never ever work for this.

The largest outlier is at 5, and the average I'd say is around 1.6 ms.

They assume they have spare cycles, note "assist". Again, GC will never work.

I mean, what does it feel like when reality sets in and you realize poll() on a file does nothing and nfs (or any fs driver) can make your over-engineered nightmare fuelled state machine halt indefinitely?

I tried it, but I came to the conclusion that my ISP blocks packets with forged source addresses.

This is the kind of shit I want to know if I'm going to learn socket programming, I do not want to pick a textbook and be proficient in outdated and bad practices. I don't know how to stay current though, looking through the internet you will find plenty of recommendations that may have been good when they were recommended but no longer are, it worries me.

How do you know? Even if it "worked", you wouldn't get any reply...

Typical sockets programming isn't really complicated enough to warrant a real textbook. My advice to you is to avoid anything dealing with windows and winsocks; start with POSIX instead. From there, you can learn about how winsock butchers the socket API and how you can deal with it. Most of the complexity in windows sockets is because of windows and winsock.

The other side I was testing with was set to report back to me through an alternative channel. When the packet was sent with my IP as the source it went through fine, but was never received when I had a different source address.

It's historical baggage. It's been recognized as a mistake since the '90s which is why all new functionality has been improving non-blocking while making blocking worse/deprecated. This shouldn't even be a controversial statement, it's widely understood.
So you're in college and getting mentally poisoned by the Jews, got it.
Not because it's the right thing to do, but because so many attempts to replace it in Linux have failed. It's embarrassing that we never got a proper disk scheduler before disks became irrelevant. We should be able to communicate our intent to the kernel for many files and have it schedule the read head to minimize seeking but since that could require thousands of threads today due to blocking calls no one does it.
Try writing code to manage 10k blocking sockets, cancellable within a few microseconds, with affinity for specific processors, and delayed (batched) reads for performance and then get back to me on how much easier it was. Yes, it's easier to do Hello, World. No one cares.

There's a ton of outdated & bad info, though. I still see people using select() and gettimeofday() like it was 1991. Those create real problems today, they aren't just autism over APIs.

My simple HTTP lib can handle connections with one thread per faster than your async horror if we're talking tiny loads like 10k. This is because, believe it or not, kernels that aren't NT have good schedulers and can start hundreds of thousands of threads per second without issue.
I would applaud your stupidity if you had the courage of your convictions. Windows has the best async kernel interface that's ever existed. Unix people genuinely praise it to high heaven. I suggest you leave the world of Thompson, Ritchie and Pike in favor of NT. It has all your favorite features and is designed by people who believed the exact same voodoo you do.
The reason no one in their right mind writes an async fs driver is presumably the same reason that one of the largest companies in the world has only managed to shit out two half-baked file systems in as many decades. If you'd ever written anything remotely complicated you'd have an appreciation of how much state machines suck. Instead you're writing simple software that breaks the second I, ironically, throw networking at it, under the delusion that it's faster because you're setting processor affinity and doing things in the way that requires by far the most effort.
The only thing async garbage has going for it is memory consumption, where you geniuses generally forget about the massive socket buffers held by the kernel. The irony again being that due to the super shitty APIs for async connection handling, you're incurring more syscalls and therefore more context switching than the sync design, while complicating the code to a ridiculous degree, achieving higher throughput at massive (1M+) loads at the cost of much higher latency at all loads. Perf, use it.

You've obviously never done this stuff before. The rest of your post is LARP I'm going to ignore. Benchmarks or GTFO - stop shitting up a decent thread.

That's a nice form of ad hominem, but it just means you concede.
not him btw fam

holy shit this went from a rewrite of a shitty irc server in a shitty language to a guy LARPing and circlejerking about windows(and that's coming from an obsessive fan of w2k)

What should be used instead of select?

Depends on OS, for Linux use epoll_wait(). Worst case, poll() will at least avoid the code incompatibility/crash issues with select() but it doesn't scale. Never use select().

missed one of the bigger problems: casting the return of malloc

Looks ok to me, what'd I miss?

why even live

I've written an IRC bot in Python with the socket module. Does that count fam?

docs.python.org/3/library/socket.html

Maintaining buffers for incoming and outgoing data is shit though. And doing multi-threaded parsing + processing with multiprocess was even worse.

fug, meant multiprocessing

Multiprocessing? As in, multiple OS processes? How did that benefit you?

I was doing shit like fetching pages and doing other miscellaneous shit in the background. Don't want that all to go on the main thread. Asyncio didn't exist so I just used multiprocessing.

Looking back it probably would've been better to just use the threading module. I didn't use it because I foolishly thought parsing IRC messages would be time-consuming which it is not .

It was my first pseudo-serious project, so it was a stupid design decision, but hey: doesn't matter, shipped code.

fug

meant for
(checked)

Python "threading" in cpython is hopelessly shit because of the gil. I'd just pretend it isn't there. Multiprocessing is one way to work around it but it's a lot heavier and very fragile as the people who wrote it had no idea what they were doing (to be fair, roughly zero people fully understand Linux process management). The 'best' way in python is entirely separate processes coordinating in some way but that's an involved setup and eats memory.

There's no need to do that. Void pointers are promoted implicitly.

You shouldn't get in the habit of writing code that only compiles with a C compiler. Omitting the cast is an error when compiled as C++. Same goes for using reserved words in C++ in C.

You should never compile C code as C++, so omitting the cast prevents retards from doing this kind of brain-damaged shit.

(checked)
That's quite naive as C/C++ code tends to move around a lot in the real world, especially in networking.
Good programmers don't deliberately create incompatibilities where there was no reason to.

Nobody in their right mind would compile C code as C++. Maybe you can do that with your toy projects and hello worlds, but in industry it's a no-go.

I'm the lead developer at a networking company. This happens so often it's baked into coding standards at many companies. At a minimum, I don't know of anyone allowing C++ incompatibilities in headers - guess what happens when you move code like this into a macro? Do it right, faggot.

Why would you intentionally create an ABI nightmare?

For the ABI? I'm confused, are you under the impression that using C++ means not linking to C libraries?

No, I'm saying compiling C code as C++ will result in name mangling, a hard dependency on the c++ lib of your compilers choice, on some platforms the need for SEH headers on functions, unwind tables, rtti, and __cxa symbols or equivalent.
Why would you voluntarily subject yourself to this when you could compile the code as C and avoid all that?

Small sections of code mix together as trying to keep them separately compiled isn't practical. Poking through our code for examples, recently a section of CMSG code migrated from one of the C projects to one of the C++ projects. CMSG code gets very complicated (and 99.99% of the documentation is wrong) but it's also small and very specific. It's a poor candidate for turning into a function that could be separately compiled, especially since the translation to C++ added some C++ features.

There's no ABI problem here, though. ABI problems are when you have reserved words as symbols, everything else is easy to manage via extern "C". API problems are more common, like C-only casts in macros. Coding guidelines that mandate avoiding needless incompatibilities prevent these problems. "No gcc-isms" is another common one, although I allow them here as we'll never be portable from Linux anyway.

You're coming at this from the opposite angle. I thought it was a question of compiling a full C project as C++, not having a C++ project and putting in a bit of C code. In the latter case it's perfectly reasonable to compile the C as C++. Not doing so could in fact become an issue because of mismatching debug info and lack of unwind tables. And yes, the cmsg API is fucking cancer.

On what I meant with ABI nightmare: I'm not talking about the odd function called template(), which would be an API thing. The problems I listed off half-heartedly all relate to dependency management.
Mixing a little bit of C++ in with C will taint your C and force you to link in a lot of C++ junk. This will, for one, complicate static linking immensely, but is also highly compiler dependent. There's the odd C compiler feature that depends on libc interaction with the compiler (stack-proctector for example depends on libc maintaining a per-thread canary) but C++ compiler take this to the extreme by omitting a runtime library in favor of libstdc++ or equivalent. Worse yet, with dynamic linking it's not always obvious when this needs to be shared, so it's unclear whether such a runtime library could be statically linked like libgcc/compiler-rt can (and should be for everyone's sanity).
Compiling your C code as C++ just makes everything a lot harder than it needs to be, especially with name mangling which doesn't always play nice with debug tools or at the very least requires a fair bit of effort.

Btw, this used to happen sometimes due to shitty embedded compilers/SDKs, like with BREW. We used libxml2 with BREW that way. .NET Compact Framework also required it for the p/invoked DLLs for some reason but I wasn't directly involved with it (Microsoft doesn't really support C although they pretended to for a while).
A C project with some C++ is a C++ project. It's fine, no one expects otherwise. We do have libraries written in C++ that expose a C API, though. There's little cost to doing so anymore since libstdc++ was shrunk and space isn't as critical as it once was. It adds about 1MiB to a base image.
Not that I'm aware of (to the user). At least not on Linux. I mean, you can force problems by asking a C compiler to link C++ objects but that's silly.
Nah, mangling is fine these days. It's not been an issue on Linux since the '90s as far as I'm aware - no more passing objdump/nm through c++filt. g++ can even demangle at runtime now via abi::__cxa_demangle which is nice for error logging and debugging templates.