Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

21

There are definitely pros/cons about using JSON over REST vs. straight up TCP/IP with binary protocol and I think you are already suspecting that binary protocol will be faster. I can't tell you exactly how much faster (and this would depend on a lot of factors), but I would guess maybe 1-2 orders of magnitude difference. At first glance if something is 10-...


12

Depends on if you're talking about peer-to-peer, client/server with the users running the server, or client/server with a data center running the server. Only in the latter-most case is the internet really fast and reliable. Your users' computers are not guaranteed to be fast, and certainly won't be reliable. UDP allows you greater control over the sort of ...


10

TLDR: The major drawback you might notice when multiplexing multiple channels on top of TCP (if you do it right) is an increased latency because of head-of-line blocking between the channels. Corollary: If you don't care about latency you should be fine. On the other hand using a single TCP connection “means less competition with other flows and longer-...


9

I know the TCP protocol binds itself to a port till the transfer of messages is over (port 80) A TCP connection is uniquely identified by the 4-tuple (source address, source port, dest address, dest port). The source and destination IP addresses will take care of themselves, but you're slightly confused about the ports. A port is just a 16-bit integer, ...


9

What's wrong with plain old garden variety FTP (File Transfer Protocol), or even TFTP (Trivial File Transfer Protocol)? Granted, they're older than your father's memory of his first kiss, but they still work. Now, both FTP and TFTP want the file to be on the server before they serve it to download clients. If what you want is to stream the file from A ...


8

For example, while searching for low-latency open source apps I found this OpenPDC application on Github which seems to be the de-facto standard application for "high-performance data collection" used by numerous utilities around the world. It's even used in academic articles as the tool for assessing network delays for the measurement devices. And yet, the ...


6

Listening ports are used in servers. If you have an apache web server for example, it does not know in advance when it will be used. Listening means that it just waits (like a recepcionist in a hotel :) and it is ready to send an answer whenever a client program (a browser for example) requests it. The connection becomes open when a client connects to that ...


6

The OSI stack is a rather theoretical model (and standard) for networking layers, but it has little practical relevance and mainly survives as a subject of CS classes. TCP/IP is a suite of concrete networking protocols that have seen overwhelming adoption on the internet. It roughly maps to the layers 3 and 4 in the OSI model. Concrete protocols rarely fit ...


5

Yes, size matters. Your co-worker's argument is that any amount of traffic up to the MTU will take the same amount of time to transmit, and that simply isn't true. Forget for a minute that you have any protocols at all, just a pipe where bits go in one end and (hopefully) make out out the other. If the pipe can transfer 8,000 bits per second, 500 bytes (4,...


5

Your book is talking about system interface for sockets, which is a bit different from real TCP socket. TCP RFC doesn't say about "welcoming socket". So, let's look at definitions. From RFC: The "three-way handshake" is the procedure used to establish a connection. So, what is connection? connection - A logical communication path identified by a ...


5

How about TLS (SSL)? I'm not familiar with the details, but I do know it's a pretty transparent layer that will allow you to use whatever protocol you are already using. Use the protocol over TLS instead of TCP, it will require some changes to API calls but the sockets methodology will remain.


4

The sequence numbers in TCP wrap around. This means that after 2^32-1 (4294967295), the sequence numbers continue with 0. You might think that this could pose problems with distinguishing between old and new data with the same sequence number, but that doesn't happen, because TCP also has the concept of a window of acceptable sequence numbers and that window ...


4

TCP is a stream protocol (not packets as you clearly said). The TCP stack layer will only deliver the data in stream order. Async or not, the data will not be handed to the client out of order. TCP would not be a very good streaming protocol if it did deliver data out of order. That's kind of the point of the protocol. :-)


4

Actually, I think you've got it backwards. At the low level of the internet, there is no such thing as polling. Everything on the internet actually pushes. Internet messages are made of packets, which are basically bunches of electrons travelling down wires. From the computer's perspective, packets simply show up either as electrons coming down a wire or ...


4

The socket returned from accept keeps the same port you were listening on originally. Only the full (client address:port, server address:port) 4-tuple needs to be unique, and the client end is already unique, so the server doesn't need to waste an ephemeral port number. As an aside, this also makes it much easier to see, eg. all your HTTP sockets using ...


4

UDP vs TCP UDP is lightweight, stateless, and lossy. TCP is heavy, statefull, and robust. UDP is best when transmission errors can be ignored. TCP is best when transmission errors need correction. Voice over IP uses UDP because of how time sensitive voice conversations are. It's better to just hear a hiccup and be back in sync then to ask for another copy ...


3

Answering this question with hard numbers would require knowing the number of clients, the quality of their network connections, the distances between them, each other and the server, how quickly the server responds to every possible request (at peak times!), and all sorts of other details. I would guess that the quality of their connections is probably ...


3

Theoretically, this could be done, but in practice, you'll probably need to find somewhere else to store that information. Each end of the connection is allowed to choose any arbitrary number it wants, but using anything other than a completely random number leaves a gaping vulnerability to certain types of attacks. This might be acceptable to you, if the ...


3

I would probably do a proof of concept using http and check the performance. No point in reinventing the wheel if it isn't necessary.


3

The OSI model is a networking model. DECNet has evolved from a 4 layer model to the OSI model. TCP/IP is a different model and implementation of a network stack. As they are different models and implementations, there is normally no question of interoperation between the two. If this needs to be done, a network bridge might be used. In terms of modelling ...


3

The limitations of Client / Server implementations are well known. Moving from a stand alone application to a client/server approach introduces some new issues for you to manage. The Server will have multiple connections simultaneously. Handling this efficiently enough without having different clients causing contention on the database should be straight ...


3

Once upon a time, there was a great war being waged between two mighty armies, the CISCites and the RISCites. The men of RISC believed that their forces were mightier, for their instruction sets were simpler. The lumbering CISCs, they said, had to have a heavy translation layer in between the instruction set and the actual execution, in which instructions ...


3

Yes, this separation of layers is always a good thing, even if its not going to be written for a distributed system. Many systems work by making UI or DB components as isolated as possible to allow for easier maintenance or replacement in the future. Other system write the main program as a command line app and then write a GUI to drive that. That allows it ...


3

It sounds like your database comes in too early in the process. I would go with a light queuing solution maybe ZeroMQ? (not sure what you can run on your devices) the key thing I think is for the 'another software' respond directly to the message before putting it in the DB. That would reduce your database load to just inserts and allow you to scale up ...


3

I'd say you need to read the ZeroMQ Guide, the patterns it gives with the reasons and disadvantages are essential reading. But otherwise, there's no problem with disconnecting the network channel from your application data delivery. You will have to take on the muxing and demuxing of data packets sent (and I would recommend a packet-based architecture here,...


3

Since the SmtpClient is not fully thread safe and can not send multiple emails at the same time, the only way to build a scalable and performant solution is to make your own pool of SmtpClient instances. A simple implementation would be along the lines of Write an EmailSender class and register as a singleton with your IOC container. Make it create a Queue ...


3

It would be an assumption to say "Internet is now pretty fast and reliable" as @Ordous pointed out, and a dangerous one too. The reason why UDP+custom protocol for delivery-critical packets does magic on most games is that, there are times when it could be "okay" if you lose some packet (just for. e.g. secondary non-critical events to complete game play), ...


3

Each NGINX worker process is initialized with the NGINX configuration and is provided with a set of listen sockets by the master process. The NGINX worker processes begin by waiting for events on the listen sockets - Inside Nginx Architecture worker processes accept new requests from a shared "listen" socket - The architecture of open source ...


3

I would recommend looking at distributed pub/sub frameworks. Even if you decide to implement it yourself with TCP/IP instead of using the framework, their architecture should still provide inspiration. ZeroMQ handles this use case, and so does Redis. You can read about how ZeroMQ handles pub/sub here. Redis does distribution by sharding the dataset into ...


Only top voted, non community-wiki answers of a minimum length are eligible