4 ms·

This is the first time I heard about Gopher. Why it's a terrible protocol?

kalleboo 13y ago
For one, file types are represented by a single ASCII character http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_types http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_t...
- njsg 13y ago
  And you need more because... Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is. You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image
  - frezik 13y ago
    Because I want to differentiate between JPEG, GIF, and PNG images? The how is going to be different for each one. Without the protocol telling me, I can only make a reasonable guess on how to process it.
  - dragonwriter 13y ago
    > Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is. How you are going to deal with it is a function of what kind of file it is, so to know the former you need to know the latter. The internet Media Type system is far from perfect, but much better. > You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image If that was really all you needed, you wouldn't need the subtypes in the internet Media Type system, while experience in the real world has shown that you do need that information.
frezik 13y ago
There are certain modes where it simply cuts the connection when the server is done transmitting. There's no length header or end-of-transmission character or anything like that.
- frezik 13y ago
  I did a more complete writeup on Gopher's problems here: http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/ http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/ Once I did a little research and wrote it all out, Gopher actually came out worse than I thought. Even if it were brought up to Gopher+ specifications (which haven't been implemented by anyone in 20 years), it would still be way behind HTTP/1.1 in terms of fixing design flaws.
  - njsg 13y ago
    You are criticizing gopher from the point of view of "it must have the same features as HTTP". Some of the things you call "problems" are just different ways of doing it. And if the TCP sliding window is an issue for you, why not fix TCP? Why should the server send any kind of header? Doesn't TCP do checksums, already?
    - frezik 13y ago
      No, these are design flaws that anything over TCP/IP needs to deal with. In particular, closing the connection to indicate the end of a file transfer is really bad (what if somebody pulls an ethernet cord?) Fix sliding window? I don't think you understand TCP. This is an optimization to TCP to prevent the need to ACK every packet. It means fewer bytes on the wire and less CPU load for TCP processing, while also maintaining a respectable degree of reliability. TCP checksums are not sufficient for data streams of more than a few kB.

For one, file types are represented by a single ASCII character http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_types http://en.wikipedia.org/wiki/Gopher_(protocol)#Gopher_item_t...

njsg 13y ago
And you need more because... Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is. You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image
- frezik 13y ago
  Because I want to differentiate between JPEG, GIF, and PNG images? The how is going to be different for each one. Without the protocol telling me, I can only make a reasonable guess on how to process it.
- dragonwriter 13y ago
  > Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is. How you are going to deal with it is a function of what kind of file it is, so to know the former you need to know the latter. The internet Media Type system is far from perfect, but much better. > You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image If that was really all you needed, you wouldn't need the subtypes in the internet Media Type system, while experience in the real world has shown that you do need that information.

frezik 13y ago

There are certain modes where it simply cuts the connection when the server is done transmitting. There's no length header or end-of-transmission character or anything like that.

frezik 13y ago
I did a more complete writeup on Gopher's problems here: http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/ http://www.wumpus-cave.net/2013/10/27/why-gopher-is-awful/ Once I did a little research and wrote it all out, Gopher actually came out worse than I thought. Even if it were brought up to Gopher+ specifications (which haven't been implemented by anyone in 20 years), it would still be way behind HTTP/1.1 in terms of fixing design flaws.
- njsg 13y ago
  You are criticizing gopher from the point of view of "it must have the same features as HTTP". Some of the things you call "problems" are just different ways of doing it. And if the TCP sliding window is an issue for you, why not fix TCP? Why should the server send any kind of header? Doesn't TCP do checksums, already?
  - frezik 13y ago
    No, these are design flaws that anything over TCP/IP needs to deal with. In particular, closing the connection to indicate the end of a file transfer is really bad (what if somebody pulls an ethernet cord?) Fix sliding window? I don't think you understand TCP. This is an optimization to TCP to prevent the need to ACK every packet. It means fewer bytes on the wire and less CPU load for TCP processing, while also maintaining a respectable degree of reliability. TCP checksums are not sufficient for data streams of more than a few kB.