All Comments
TopTalkedBooks posted at August 20, 2017

Your question requires more than just a stack overflow question. You can find good ideas in these book:

Basically what you're trying to do is a reactor. You can find open source library implementing this pattern. For instance:

If you want yout handler to have the possibility to do more processing you could give them a reference to your TCPServer and a way to register a socket for the following events:

  • read, the socket is ready for read
  • write, the socket is ready for write
  • accept, the listening socket is ready to accept (read with select)
  • close, the socket is closed
  • timeout, the time given to wait for the next event expired (select allow to specify a timeout)

So that the handler can implement all kinds of protocols half-duplex or full-duplex:

  • In your example there is no way for a handler to answer the received message. This is the role of the write event to let a handler knows when it can send on the socket.
  • The same is true for the read event. It should not be in your main loop but in the socket read handler.
  • You may also want to add the possibility to register a handler for an event with a timeout so that you can implement timers and drop idle connections.

This leads to some problems:

  • Your handler will have to implement a state-machine to react to the network events and update the events it wants to receive.
  • You handler may want to create and connect new sockets (think about a Web proxy server, an IRC client with DCC, an FTP server, and so on...). For this to work it must have the possibility to create a socket and to register it in your main loop. This means the handler may now receive callbacks for one of the two sockets and there should be a parameter telling the callback which socket it is. Or you will have to implement a handler for each socket and they will comunnicate with a queue of messages. The queue is needed because the readiness of one socket is independent of the readiness of the other. And you may read something on one and not being ready to send it on the other.
  • You will have to manage the timeouts specified by each handlers which may be different. You may end up with a priority queue for timeouts

As you see this is no simple problem. You may want to reduce the genericity of your framework to simplify its design. (for instance handling only half-duplex protocols like simple HTTP)

TopTalkedBooks posted at August 20, 2017

Do yourself a favor: go read at least first 6 chapters of this Steven's book in which you can find plenty of simple examples and many advices how to avoid common pitfalls with network programming. Without doing that you will end with a buggy, slow and incomplete client.

TopTalkedBooks posted at August 20, 2017

Edited because I had to leave a meeting when I originally submitted this, but wanted to complete the information

Half of that material is learning about development in a Unix-like environment, and for that, I'd recommend a book since it's tougher to filter out useful information from the start.

I'd urge you to go to a bookstore and browse through these books:

  • Advanced Programming in the Unix Environment by Stevens and Rago - this book covers threads, networking, IPC, signals, files, process management
  • Unix Network Programming, Volume 1 by Stevens - This book is focused on network programming techniques, design - you might not need this until much later
  • Unix/Linux System Administration - This book covers the more system administrator side of stuff, like directory structure of most Unix and Linux file systems (Linux distributions are more diverse than their Unix-named counterparts in how they might structure their file system)

    Other information accessible online:

  • GCC Online Manual - the comprehensive GNU GCC documentation

  • Beej's network programming guide - A really well written tutorial to network programming with the use of the BSD API. If you have done work with winsock, this should be mostly familiar to you.
  • Red Hat Enterprise Linux 5's Deployment Guide - talks specifically about Red Hat EL 5's basic administrative/deployment, like installing with package manager, a Red Hat system's directory structure...
  • make - Wikipedia article that will have links to the various make documentation out there
  • binutils - These are the Linux tools used for manipulating object/binaries.
  • GNU Build System - Wikipedia article about the traditional build system of GNU software, using autoconf/automake/autogen

Additionally, you will want to learn about ldd, which is like dependency walker in Windows. It lists a target binary's dependencies, if it has any.

And for Debugging, check out this StackOverflow thread which talks about a well written GDB tutorial and also links to an IBM guide.

Happy reading.

TopTalkedBooks posted at August 20, 2017

Linux is the most accessible and has the most mature desktop functionality. BSD (in its various flavours) has less userspace baggage and would be easier to understand at a fundamental level. In this regard it is more like a traditional Unix than a modern Linux distribution. Some might view this as a good thing (and from certain perspectives it is) but will be more alien to someone familiar with Windows.

The main desktop distributions are Ubuntu and Fedora. These are both capable systems but differ somewhat in their userspace architecture The tooling for the desktop environment and default configuration for system security works a bit differently on Ubuntu than it does on most other Linux or Unix flavours but this is of little relevance to development. From a user perspective either of these would be a good start.

From a the perspective of a developer, all modern flavours of Unix and Linux are very similar and share essentially the same developer tool chain. If you want to learn about the system from a programmer's perspective there is relatively little to choose.

Most unix programming can be accomplished quite effectively with a programmer's editor such as vim or emacs, both of which come in text mode and windowing flavours. These editors are very powerful and have rather quirky user interfaces - the user interfaces are ususual but contribute significantly to the power of the tools. If you are not comfortable with these tools, this posting discusses several other editors that offer a user experience closer to common Windows tooling.

There are several IDEs such as Eclipse that might be of more interest to someone coming off Windows/Visual Studio.

Some postings on Stackoverflow that discuss linux/unix resources are:

If you have the time and want to do a real tour of the nuts and bolts Linux From Scratch is a tutorial that goes through building a linux installation by hand. This is quite a good way to learn in depth.

For programming, get a feel for C/unix from K&R and some of the resources mentioned in the questions linked above. The equivalent of Petzold, Prosise and Richter in the Unix world are W Richard Stevens' Advanced Programming in the Unix Environment and Unix Network Programming vol. 1 and 2.

Learning one of the dynamic languages such as Perl or Python if you are not already familiar with these is also a useful thing to do. As a bonus you can get good Windows ports of both the above from Activestate which means that these skills are useful on both platforms.

If you're into C++ take a look at QT. This is arguably the best cross-platform GUI toolkit on the market and (again) has the benefit of a skill set and tool chain that is transferrable back into Windows. There are also several good books on the subject and (as a bonus) it also works well with Python.

Finally, Cygwin is a unix emulation layer that runs on Windows and gives substantially unix-like environment. Architecturally, Cygwin is a port of glibc and the crt (the GNU tool chain's base libraries) as an adaptor on top of Win32. This emulation layer makes it easy to port unix/linux apps onto Cygwin. The platform comes with a pretty complete set of software - essentially a full linux distribution hosted on a Windows kernel. It allows you to work in a unix-like way on Windows without having to maintain a separate operating system installations. If you don't want to run VMs, multiple boots or multiple PCs it may be a way of easing into unix.

TopTalkedBooks posted at August 20, 2017

I suggest reading this post and then deciding for yourself based on your own knowledge of your code whether or not it's OK to ignore the ECONNRESET. It sounds like your Node app may be trying to write to the closed connection (heartbeats being sent?). Proper closing of the connection from your C# app would probably take care of this, but I have no knowledge of C#.

You may have a problem if you get lots of users and if ECONNRESET causes the connection to go into TIME_WAIT. That will tie up the port for 1-2 minutes. You would use netstat on Linux to look for that but I'm sure there is an equivalent Windows app.

If you really want to get into the nitty gritty of socket communications I suggest the excellent Unix Network Programming, by Stevens.

TopTalkedBooks posted at August 20, 2017

There is a Unix domain socket-based mechanism for transferring file descriptors (such as sockets - which cannot be memory mapped, of course) between processes - using the sendmsg() system call.

You can find more in Stevens (as mentioned by Curt Sampson), and also at Wikipedia.

You can find a much more recent question with working code at Sending file descriptor by Linux socket.

Top Books
We collected top books from hacker news, stack overflow, Reddit, which are recommended by amazing people.