Peer-to-peer GUI adapter

[diep]

I looked at your code, but it was not clear to me what the reason for the several delays was. This is really awful! One would expect that it would not be to difficult nowadays to make system calls that actually do what is requested, even if it takes time, rather than annoying the user with low-level sync problems. This is a blocking I/O call, after all...

Some of the GUI code gets written by the most brilliant as with GUI's you can make big cash (facebook huh?), but majority of the code is guys who don't know how to spell the word algorithm correct let alone that they are capable of setting up a bugfree system.

Usually coders working for bigger companies also have tons of guys like that. Education there really says nothing. It's a mixture of university guys with guys whom with hard work worked their way up. I respect that. Yet both share they have not the intellectual luggage to prove systems correct.

Windows is horrible there, yet whatever you say: it's all very WELL documented, including its features you have to program around. Oh did i quote Bill Gates there? Features rather than bugs... ...gosh my bad.

My size for the buffer was mostly inspired by the idea that a FEN for a 36x36 board could be pretty long, especially if there are so many piece types that most pieces need two letters, and you then need additional delimiters to see which letters form a pair, so that you can need 3 or 4 characters per piece...

The p2p I made is a pure engine, so no graphics thread needed. Normally I do two threads in an adapter, one for each direction of the communication traffic. But here you need to listen for incoming connections too. You don't really need to do that at the same time as handling incoming traffic, but it was a bit difficult to terminate the listening when the stdin thread decides it is time to connect as client to a remote machine. I just hope that printf is thread-safe, because all threads do a lot of printing on stdout.

Oh really, i was thinking you're the type of guy who clears his memory buffer 7 times before deallocating it. Good to know i'm wrong!

[Don]

Don't make the password stuff overly complicated. A very simple thing to avoid sending clear-text passwords is for the server to send a random string (in cleartext) to the client, then the client appends that the password they both know. The client sends back the md5sum (or sha-1, whatever) to the sever (which they can both compute) and this is relatively secure and yet still very simple.

I don't know what the difference is in how the sockets work, but the Windows code I had made could be compiled without problems under Linux, after I changed the includes and defined some macros (like INVALID_SOCKET) which apparently are not standard in Linux. And the compiled version could connect to its peer on a Windows computer.

It is good you remind me of the security issues. I guess what I have now fals short of the mark there. I must really make sure there cannot be any buffer overruns when someone tries to send toxic lines. The actual recv call contains the buffer length, of course, but then I start pasting received packets together until the input contains a linefeed, and that is the dangerous part.

It could be OK, though, as I paste them together in the receive buffer, making sure it will not overflow, and only then copy the first line it contains to the line buffer, which is of equal size:

Code: Select all

int
ReadFromPeer (SOCKET s, char *buf)
{
  int res;
  char *p, *q;
  static char rcvBuf[8001];
  static int cnt;
  while((p = strchr(rcvBuf, '\n')) == NULL) {
    if(state == DISCONNECTED) return 0;
    res = recv(s, rcvBuf+cnt, 8000-cnt, 0);
    if(!res) printf("telluser connection closed by peer\n");
    if(res < 0) {
      printf("telluser recv failed with error: %d\n", WSAGetLastError()), fflush(stdout);
      res = 0;
    }
    if(!res) return 0;
    cnt += res;
  }
  rcvBuf[cnt] = 0; p++;
  for(q = rcvBuf; q < p; ) *buf++ = *q++; *buf = 0;
  for(q = rcvBuf; p < rcvBuf+cnt; ) *q++ = *p++; *q = 0;
  cnt = q - rcvBuf;
  return 1;
}

So unless the recv call starts to act strange when the buffer length is specified as 0, it should generate an EOF condition (return 0;) when the buffer overflows, leading to the closing of the socket.

Adding a password is a good idea. I could add that as another engine string option: the client would send it after getting the 'hallo' message, and the server would then verify it for equality, and close the connection otherwise.

[diep]

Yeah i keep it supersimple in DEP.
just total unencrypted session for now.
it's only about logging in with password against the 100% sure portscanning dudes that are around.

ftp here is TLS for a week now

Note that SHA in itself is a crap algorithm. It's adding up segments in the last phase of a 256 bits or something (didn't check out the algorithm very well). Some toying at home you can get massive collissions very simple - if someone would pay for that toying.

So we can easily prove it's O ( n log n ) to get from addition to a collission, so it doesn't make sense to even consider using some sort of verification with SHA.

Those who are so sophisticated to figure all that out you are not building this for. Just a password to get in is more than plenty.