TCP is shit

If you're so lazy that you have to rely on a lower level protocol for reliability, rather than implementing your own reliability features at the application layer, it's time to stop programming.

(insert speech about not reinventing the wheel here)

>>2
(insert speech about efficiency and YAGNI here)

No, it is better to have reliability done at lower levels, otherwise protocols would be even more horribly implemented and things would be even worse.

If it were up to me, I would have security implemented at the physical layer with 1024 bit AES and 8096bit DH key bullshit.

(insert speech about not inventing future variations of the wheel)

>>3
UDP.

Well, that aspie Bram Cohen tried to follow your advice and ruined BitTorrent creating µTP.

After having actually tested the thing, as well as some other shitty homemade reliable transport protocols, I have a newfounded appreciation for TCP.

It might not be perfect, but unlike everything else, it actually works, probably because it was designed properly (as in with proofs of the desired properties), as opposed to coded by some autistic neckbread in his basement going by hunches about how networks work.

>>4
No, it is better to have reliability done at lower levels
Enjoy your unnecessary network overhead.

Real programmers send their data by using a battery and an ethernet cable cut in one end.

>>9
>cut ethernet cable
Enjoy your crosstalk.

Network programming sucks, especially on Win32 and UNIX.

On UNIX:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
  ...
struct sockaddr_in sock_in;
struct servent *sp;
struct hostent *host;
  ...
memset(&sock_in, 0, sizeof (sock_in));
sock_in.sin_family = AF_INET;
f = socket(AF_INET, SOCK_STREAM, 0);
if (f < 0)
  error("socket");
if (bind(f, (struct sockaddr*)&sock_in, sizeof sock_in) < 0){
  error("bind");
host = gethostbyname(argv[1]);
if(host){
  sock_in.sin_family = host->h_addrtype;
  memmove(&sock_in.sin_addr, host->h_addr, host->h_length);
}else{
  sock_in.sin_family = AF_INET;
  sock_in.sin_addr.s_addr = inet_addr(argv[1]);
  if (sock_in.sin_addr.s_addr == -1)
    error("unknown host %s", argv[1]);
}
sp = getservbyname("discard", "tcp");
if (sp)
  sock_in.sin_port = sp->s_port;
else
  sock_in.sin_port = htons(9);
if (connect(f, (struct sockaddr*)&sock_in, sizeof sock_in) < 0){
  error("connect:");

On Plan 9:
#include <u.h>
#include <libc.h>
...
fd = dial(netmkaddr(argv[1], "tcp", "discard"), 0, 0, 0);
if(fd < 0)
  sysfatal("can't dial %s: %r", argv[1]);

>>11
That's just on higher-level languages. I can teach the damn thing to kids with an interface like Erlang's gen_tcp and a state diagram.

>>9
Real programmers use butterflies.

>>13
No, real programmers use FIOC and Java. The others are merely hipsters and autists.

Real programmers use whatever tool suits the task. Butterflies included.

>>15
I hate people who parrot this.
We get it you're oh-so-mature and acknowledge that there are different tools for different purposes. That doesn't mean that you shouldn't use Scheme and ^_bb_code for everything where possible.

>>16
Can you write BBCODE which parses itself?

>>11
On Win32:

SOCKADDR_IN serv_addr;
int hsocket=socket(AF_INET,SOCK_STREAM,0);
serv_addr.sin_family=AF_INET;
serv_addr.sin_addr.s_addr=your_ip_addr;
serv_addr.sin_port=htons(your_port);
if(connect(hsocket, &serv_addr, 16)) {
 printf("Connection failed with error %d.",WSAGetLastError());
 closesocket(hsocket);
 WSACleanup();
 ExitProcess(0);
}

>>6
/thread

>>17
BBcode is not a programming language. You use Scheme for that.

>>17
Yes.
_
^{Note: The above BBCode was parsed by itself.}

>>1

Quite possibly the most retarded thing ever posted on /prog/.

>>21
More retarded than FrozenVoid?

>>21
I don't know. The self hating jew is quite retarded.

>>23
Doubt human mental conditions apply to jews. There is nothing, that makes jews human.

>>24
No, YOU are the self hating jews.

>>25
And then Anonymous was a kike.

>>6
Any sufficiently complicated protocol on top of UDP contains an ad hoc informally-specified bug-ridden slow implementation of half of TCP.

>>27
UDP + parity checks work just fine

>>28
Except when packets get lost or delayed or reordered in transit or one endpoint closes the socket without notice or the partners have different processing speeds/buffer-size or path MTU is not 1.5k or data needs a out-of-order path.

>>29
Or also if the internet breaks

TCP is inefficient when secure transport protocols are implemented atop of it. UDP gives you the required freedom.

... but fails in ordering the messages and delivering all of them.

UDP GNUFREEDOM

>>32
It gives you FREEDOM to implement those in application level.

>>34
It's basically writing your own TCP on top of it. And I bet it will work slower than existing one - especially if written by FrozenVoid.

>>28

UDP with parity checks don't give you shit - in fact, parity check on top of UDP gives you absolutely nothing since UDP already has a checksum. You need to also do sequence numbering because your packets will come out of order and get dropped. You need to do retransmission request and maintain a reordering buffer. You need to somehow do congestion control. In other words, you need to re-implement TCP, except you don't know shit about transport protocols so your implementation will be complete garbage.

>>31

That doesn't even make any sense. Also, SSL/TLS says "Hi!"

TCP_send(void *buff, int size){
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
 UDP_send(buff, size);
}
here, reimplemented guaranteed message tranmission in UDP. any question?

>>36
SSL/TLS is bloated shit.

>>37

It's not guaranteed, it's not congestion controlled, and it's insanely inefficient.

>>38

Which part exactly is bloated? How would you do it more efficiently?

>>39
congestion control is for pussies. just buy better internet.

TCP splits messages. reciever can recieve only half of the message at the application level right? if it is big enough.

if yes it sucks.

>>41

Oh cool, it's the 80s again?! Fuck TCP here we come congestion collapse!

>>42

There's no such thing as a "message" in TCP. Towards applications TCP provides reliable byte stream, internally it uses segments, and below packets.

>>44
meaning it is shit.

>>42
It does not provide framing, and that's an endless cause of bugs in shittily written software. Surely it's not that difficult to prepend the length to each message, and add 10 lines of code to handle the reception?

Well, I guess it would be difficult for most of today's "programmers". It'd make a nice interview question.

>>45

Meaning you have no understanding of networking protocols and should stay away from them.

>>47
I just can't understand necessity of TCP. If you need congestion control, message ordering etc it could be easily implemented in application level. any respectable language would have libraries for such task.

I am not happy with the idea of "streams" instead of "datagrams" either. It forces you to check size of input buffer at application level to check if size is correct. It shouldn't be programmer tasks.

>>48
I just can't understand necessity of TCP. If you need congestion control, message ordering etc it could be easily implemented in application level.
You must be trolling. Nobody could possibly be that stupid.

>>48

Go ahead and try to do it at application level. I guarantee you'll quickly see why it's not as simple as you think. And we do have "libraries" for congestion control, message ordering and reliable delivery, it's called TCP and it's implemented in the kernel because that's the most efficient way to do it.

Reliable byte stream and datagram abstractions are for different things, it's not a question of "liking" one, it's a question of picking the right one for the job. You do VoIP or streaming media? UDP (or more likely RTP on top of UDP) is likely the correct choice. You want to transfer files? You want TCP (possibly FTP over TCP). Want to build a generic application protocol X? You want TCP 99% of the time.

Don't like the stream abstraction? Fine, use a message based protocol that gives you framing, like HTTP for example. Guess what they're implemented on top of? Yes, TCP.

And how is checking input buffer size not a programmer task? Who should do it, fairies? What you probably mean is that writing distributed applications, at least the networking parts, is not for generic application programmers. Which I completely agree, you want to pick a protocol that gives you what you need and then you want to get an implementation of said protocol with a nice and simple API by someone who actually knows how to write networking code.

>>50
You're wasting your time. Read >>49.

>>50
Who should do it, fairies?
Fairy-Oriented Programming is the future.

>>50

And we do have "libraries" for congestion control, message ordering and reliable delivery, it's called TCP and it's implemented in the kernel because that's the most efficient way to do it.

I stopped reading after this sentence because I realized that you're the same moron that doesn't have the mental capacity to become more than a general laborer in life.