Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

TCP is shit

Name: Anonymous 2011-11-07 13:43

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.

Name: Anonymous 2011-11-07 13:46

(insert speech about not reinventing the wheel here)

Name: Anonymous 2011-11-07 13:48

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

Name: Anonymous 2011-11-07 13:58

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.

Name: Anonymous 2011-11-07 14:07

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

Name: Anonymous 2011-11-07 14:18

>>3
UDP.

Name: Anonymous 2011-11-07 14:22

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.

Name: Anonymous 2011-11-07 14:32

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

Name: Anonymous 2011-11-07 14:36

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

Name: Anonymous 2011-11-07 14:49

>>9
>cut ethernet cable
Enjoy your crosstalk.

Name: Anonymous 2011-11-07 15:01

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]);

Name: Anonymous 2011-11-07 15:05

>>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.

Name: Anonymous 2011-11-07 15:08

>>9
Real programmers use butterflies.

Name: Anonymous 2011-11-07 15:24

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

Name: FrozenVoid !!mJCwdV5J0Xy2A21 2011-11-07 15:33

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

Name: Anonymous 2011-11-07 15:46

>>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 bbcode for everything where possible.

Name: FrozenVoid !!mJCwdV5J0Xy2A21 2011-11-07 15:58

>>16
Can you write BBCODE which parses itself?

Name: Anonymous 2011-11-07 15:59

>>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

Name: Anonymous 2011-11-07 15:59

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

Name: Anonymous 2011-11-07 16:00

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

Name: Anonymous 2011-11-07 17:02

>>1

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

Name: Anonymous 2011-11-07 17:04

>>21
More retarded than FrozenVoid?

Name: Anonymous 2011-11-07 17:30

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

Name: Anonymous 2011-11-07 17:45

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

Name: Anonymous 2011-11-07 21:34

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

Name: Anonymous 2011-11-07 22:42

>>25
And then Anonymous was a kike.

Name: Anonymous 2011-11-08 10:34

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

Name: Anonymous 2011-11-08 11:24

>>27
UDP + parity checks work just fine

Name: Anonymous 2011-11-08 11:33

>>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.

Name: Anonymous 2011-11-08 11:43

>>29
Or also if the internet breaks

Name: Anonymous 2011-11-08 12:15

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

Name: Anonymous 2011-11-08 12:21

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

Name: Anonymous 2011-11-08 12:51

UDP GNUFREEDOM

Name: Anonymous 2011-11-08 12:56

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

Name: Anonymous 2011-11-08 13:42

>>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.

Name: Anonymous 2011-11-08 15:24

>>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!"

Name: Anonymous 2011-11-08 16:06

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?

Name: Anonymous 2011-11-08 16:13

>>36
SSL/TLS is bloated shit.

Name: Anonymous 2011-11-08 16:14

>>37

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

Name: Anonymous 2011-11-08 16:15

>>38

Which part exactly is bloated? How would you do it more efficiently?
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -