Did you ever had a project where you used lower level protocols directly?
Usually we use http(s), a lib like grpc or service SDKs such as for databases.
But did you ever build an app that use tcp or udp directly or define your own protocol on top of them?
Top comments (24)
Yes, i developped proprietary protocols for :
Others that are minor and that i forgot...
this sounds like some cool stuff. thanks for sharing
cool! 😲
I've used UDP before. We were experimenting on how Dos works(for educational purposes).
So when using TCP for Dos attacks the sender of the attack also gets hit with a traffic of response. So if you send 1m requests you also receive 1m responses. This becomes a resource fight not an attack. That's why mostly attacks are performed with multiple computers(DDos) so that the senders won't be hurt since it's collective.
But with UDP the requests are one-way. No response. hence might be efficient here but the problem with it is you don't seem to know whether the packet was successfully delivered.
Above was an educational research with my friends. Thanks
Yes, I am very interested actually in defending from attacks, and the best is to know and understand how attackers can work.
With Udp you mostly can only go for some network services right? the webserver is tcp so just drop the messages.
I was wondering if I could not send a response to an attacker with my node.js web server (not even the tcp termination). But it would also keep the connection open on my side as well. When closing in any way, the attacker get an 'end' package.
You do not do this at application level, so not with nodeJs.
DDOS detection/protection can be implemented at Kernel level with IPTables : javapipe.com/blog/iptables-ddos-pr...
UDP can get very nasty when it comes to DDoS. You can use so called amplification attack to DDoS servers/infrastructure. The fact that UDP is stateless means, compared to TCP, that no prior connection establishment is needed to force the remote end to processes received UDP data packets. In a firewall you can define rules that all TCP packets that did not follow an already established connection (called in TCP a 3-way handshake) can be dropped immediately.
Let's get back to the amplification. By finding a misconfigured DNS server that responds with large data (DNS UDP packet can be up to 4096 bytes large), e. g. sending a full DNS zone response with lots of DNSSec keys you can craft very small UDP DNS request that pretends to come from your victim's public IP address to the misconfigured DNS server which will happily send the response to the victim due to lack of state establishment in UDP. If you'd try this with TCP you'd have to first send SYN packet, and then respond with SYN/ACK (acknowledgement) from remote end, followed by another ACK packet to the server before being able to send/request real data packets. Since you faked the victim IP address a server would send SYN/ACK to the victim resulting in the victim to drop the packet since it never initiated the connection in the first place followed by the server closing the connection soon after due to lack of response to the handshake. This is not the case for UDP though so in one packet with few bytes forming a request you can force misconfigured server to send large response to the victim without any validation - hence the name "amplification".
Exactly, it works for some services.
I have used for port forwarding kind of. So every time I create a new application in our dev server, I have to open the port using TCP and UDP and default port 80 is used by another application.
At the time of warcraft3 I opened portforwarding on my router as well, to be able to open maps myself. Is that what you mean?
you say port 80, did you want to access a local webservice from remote?
So our main application is using the default port 8080 and hosted in IIS so that we can use the url from remote without passing the port. but if I have to deploy any other application with let's say with port 5000, I have to use UDP and TCP to open the port so that I can access the service from the remote.
personally I never used them directly productive. professional or private.
But I never get over doing some experiments. such as an http server using the node.js net(tcp) module . Or implementing a primitive
RPClibrary.While it worked and was fun to develop, I would not want to use it seriously.
I have developed a threaded TCP server for one project talking proprietary binary protocol. We received an IoT device that could only speak TCP (updating the code to support MQTT deemed too expensive as it was an 8bit ATMEL chip based solution with poor protocol support) and it didn't go very well. It turned out that sometimes the device decided randomly to insert PSH (TCP PUSH) flag to bigger packets that resulted in the TCP server trying to process data with the PSH flag immediately instead of waiting for the remaining split packet. This caused application errors because data was truncated and following packets were missing beginnings. After a week of debugging they could not find the problem let alone fix it so I had to implement higher level virtual packet reassembly in my TCP server to mitigate the issue. Luckily this device was soon replaced by one that speaks certified MQTT...
Nothing big, but several small tools that use UDP, like (abandoned) a linux client for battleye rcon, a simple protocol for controlling LEDs (switched to MQTT instead) and probably more stuff that I can't remember.
I was working on a project that includes a hardware device based on STM32. I had to use bare TCP connection with app written in electron to make communication possible. It was simple protocol based on simple frames with headers describing what is sent.
Never 😬
yes that is what I expected.
can all others like @itsjzt comment if you never used UDP and TCP?
Yes. I have used udp and tcp to build a p2p network protocol like kademlia and upnp and bonjure for embedded system and a special repeater.
Basically, it uses several methods to establish a connection.
Besides that , I used for the server-side low-latency game library etc..
Yes, UDP for Kademlia P2P implementations.