This is my first set up of a webserver, so it's an experimental learning experience.
I had successfully got lighttpd using mod_fastcgi (https://redmine.lighttpd.net/projects/1/wiki/docs_modfastcgi) working to send a request to a separate process via a TCP socket. It sends the request using the FastCGI protocol.
But is there a module or way to send raw data to the TCP socket without the FastCGI protocol? Alternatively, if not lighttpd, is there another lightweight webserver that does allow sending basic requests to a TCP socket without any extra protocol wrapping around it?
I think you are looking for lighttpd mod_proxy.
https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModProxy
Related
Here is my understanding of how a client-server HTTP server works.
The client creates a TCP socket connection to connect to the server and sends data.
The server creates a TCP socket connection to listen for incoming requests.
So it looks like both the client and the server need to agree on the use of the Transport protocol to use (in this case TCP). But if we want a website to work over UDP/QUIC protocol then we need both the client and the server to create a UDP socket connection. But some websites use TCP and others use UDP...
So does it mean it would need to look like this? To know beforehand which protocol a website uses?
if (URI == 'https://www.google.com') {
// Website that works over UDP
client.create.UDP.socket
client.sendData
server.create.UDP.socket
server.receive.data
} else {
// Website that works over TCP
client.create.TCP.socket
client.sendData
server.create.TCP.socket
server.receive.data
}
So the client needs to keep a record of which website uses TCP and which websites use UDP/QUIC and create that kind of socket to communicate with it?
If a protocol supports both TCP and UDP, the server listens both on the TCP port and the UDP port. The port number is generally the same, e.g. DNS uses TCP port 53 and UDP port 53.
Usually the client has a preference. Let's say it prefers TCP. The client will first try to connect with TCP. If the server does not respond, the client will retry with UDP. Alternatively, the server can respond over TCP but ask the client to switch to UDP. The client can then decide to continue with TCP or switch to UDP.
For QUIC 1 2, the browser will first connect using HTTP over TCP. The server will respond with a message stating that it also supports QUIC. If the browser also supports this protocol, the browser will reconnect to the server using QUIC.
Just some concept about TCP Socket, let's say there are 100 clients simultaneously communicating with a traditional HTTP/TCP web server. How many sockets are respectively at the server and at each client? Do all of the sockets at the server
have the same server-side port number?
The question is generic, so the answer is going to be as well.
For traditional TCP-based HTTP server, there will be 100 sockets on the server (one for each client), and one socket on every client. All server sockets will be bound to the same server port.
This answer doesn't take into account the fact that in modern HTTP model a client usually opens more than one socket to serve a single request.
I have been going through this websockets article.
Can a web-socket communicate with a TCP/UDP Socket and viceversa?
Websockets use TCP sockets.
Websockets are a higher level technology relying on TCP sockets, exactly the same way HTTP is transported over TCP sockets.
In fact, Websockets are a special extension of HTTP. The client issues a special HTTP request that leaves the underlying TCP socket open, which then allows both the client and the server to push data on the connection.
What you essentially need is a WebSockets client library in your application. This will utilise TCP sockets on a lower level, and talk to your webserver using the WebSockets protocol.
The benefit of this approach is that your application code only has to deal with the library's higher-level API as well, instead of the nitty-gritty sockets API, where you'll have to implement HTTP and/or WebSockets again.
I have a game I am working on and I heard that UDP is superior for real-time games. I know that socket.io uses TCP and was wondering if there is some way to switch it to UDP. I tried looking it up but only found posts from around 2012 which said UDP is only experimental in browsers.
From a standard browser, it is not possible.
From a browser client, socket.io uses either the http or the webSocket transport. Both http and webSocket are TCP connections, not UDP connections. So the browser client socket.io does not use UDP - it uses TCP.
As best I know, there is no standard UDP support in browsers accessible from regular HTML page Javascript so you can't even really try to build your own layer that uses UDP.
Other references on the topic:
Why Can't I Send UDP Packets From a Browser
Reading from udp port in browser
Chrome Supports TCP and UDP Sockets
Write a chrome extension to support UDP in browser
How to send a UDP Packet with Web RTC - Javascript?
How to talk to UDP sockets with HTML5?
Reading from udp port in browser
UDP can be a desirable transport for some circumstances when you want the packet to be delivered as soon as possible, but if it can't be delivered immediately, then just drop it. This is sometimes useful in gaming or even video streaming where the next packet will just contain the next update so if the previous one didn't come through, then no big deal and you'd rather not have TCP try to retransmit the lost packet. But, browsers don't support using the UDP protocol from web page Javascript.
If you want to connect to a UDP device or server from a browser, you will have to use some sort of proxy so your browser code can talk to the proxy over TCP (either http or webSocket) and then the proxy can handle the actual UDP communication with the device.
It would be possible to use the socket.io library from node.js or some other non-browser platform and write your own UDP transport add-in for socket.io that is built on the native UDP support in your platform. I believe socket.io has a somewhat pluggable transport so you could try to make your own transport and then configure both client and server to use that transport. This is not possible from the browser (without a native code plug-in installed in the browser) because there's no underlying UDP support in the browser that you could build your transport on, but in non-browser environments like node.js, you could do that.
It might be a good idea to use webRTC in this case which is UDP in nature.
Although the question is already answered, I want to point out that there are ways to implement socket.io with UDP. For example dgram does exactly what you are looking for.
This is a tutorial for socket.io + UDP with dgram.
UPDATE:
Alexandre Lacheze developed a node.js package that brings UDP to browser. It also supports socket.io. So the answer is somehow obsolete now.
UPDATE 2:
It turn out it is just a simulated UDP. Not an actual UDP protocol running on browser.
I have installed a streaming server "Lighttpd" (light-tpd) which runs on port 81.
I have a C program that listens to http requests on port 80 using a server socket created by socket api.
I want that as soon as I get a request on the port 80 from a client I forward that to the streaming server and the remaining conversation takes place b/w the Streaming Server and client & they bypass my C program completely.
The problem is client would be expecting msgs from socket at port 80 (i.e from the socket of my C program) since it had sent request to port 80 only rather than from the Streaming server which gives service on port 81.
can anyone help me out on this issue of bypassing the socket on port 80 for replying to the client.
Solution I think: my program can be a middle man...It will forward the request to port 81 of streaming server and when it get replies from there it forwards them to the client...but bypassing would be efficient and I don't know how to do that. Please help me out.
Thanks in advance
Why put your C program in front? Lighttpd is designed to act as a frontend proxy (among other uses), so you can put lighttpd in front and use its mod_proxy_core to pass requests to your C program. You can use X-Rewrite and/or X-Sendfile to pass requests back to Lighttpd after doing some processing inside your application.
I have recently implemented a similar technique where a single program accepts a TCP connection and then 'passes' that connection to another component and plays no further part in the socket conversation. It uses the technique of passing the file descriptor of the accepted socket over a UNIX socket to the server component which effectively does an inter-process dup() of the fd.
See here and here.
This works for me as I have control of both ends of the UNIX socket on the server-side, but to work for you, you'd need:
A UNIX socket between your dispatching component and server components.
Full control of the server component.
You might need to hack away at the lighttpd source code...
Sorry, not really an proper answer...