A kiválasztott változat és az aktuális verzió közötti különbségek a következők.
Előző változat mindkét oldalon Előző változat Következő változat | Előző változat | ||
tanszek:oktatas:iss_t:integration_based_on_tcp_ip_sockets [2023/03/06 07:51] knehez |
tanszek:oktatas:iss_t:integration_based_on_tcp_ip_sockets [2024/02/25 15:43] (aktuális) knehez [Blocking and non-blocking TCP sockets in Java] |
||
---|---|---|---|
Sor 1: | Sor 1: | ||
- | ===== Socket communication ===== | + | ===== TCP - Socket communication ===== |
The client sends requests to the server over a TCP socket connection, and the server responds to these requests. Here are the basic steps involved in integrating software systems or components using TCP socket communication: | The client sends requests to the server over a TCP socket connection, and the server responds to these requests. Here are the basic steps involved in integrating software systems or components using TCP socket communication: | ||
Sor 27: | Sor 27: | ||
{{:tanszek:oktatas:iss_t:sockets-blocking-nonblocking.png?800|}} | {{:tanszek:oktatas:iss_t:sockets-blocking-nonblocking.png?800|}} | ||
- | Reading: | + | Blocking and non-blocking TCP sockets differ mainly in handling input/output (I/O) operations, particularly regarding how a program's execution flow is managed when waiting for operations to complete. Here's a breakdown of the main differences: |
+ | |||
+ | === Blocking sockets === | ||
+ | |||
+ | **Execution Flow**: In the case of blocking sockets, when a socket operation (like recv or send) is called, the program's execution is "blocked" until the operation completes. For example, if you call recv to read data from a socket, the call will wait forever until data is received. | ||
+ | |||
+ | **Ease of Use**: Blocking sockets are straightforward to use and understand because the operations appear sequential and synchronous. The program will not proceed until the current operation finishes, simplifying the logic, especially for simple networked applications. | ||
+ | |||
+ | **Performance Considerations**: While //blocking sockets// are easier to work with, they can lead to inefficient use of resources. For instance, if a server implemented with blocking sockets handles multiple connections, it would need //to spawn a new thread or process for each connection to avoid one operation blocking the entire server//. | ||
+ | |||
+ | === Non-Blocking sockets === | ||
+ | |||
+ | **Execution Flow**: Non-blocking sockets, on the other hand, allow the program's execution to continue immediately, even if the socket operation cannot be completed at that moment. | ||
+ | |||
+ | **Complexity**: Because the program continues to run even when data is not immediately available, using non-blocking sockets can lead to more complex program structures. Developers often use event loops or select/poll mechanisms to efficiently manage these sockets, especially when handling multiple connections simultaneously. | ||
+ | |||
+ | **Performance and Scalability**: Non-blocking sockets can lead to more efficient and scalable applications. A single process or thread can manage multiple socket connections without spawning new threads or processes for each connection, using system resources better and enabling the server to handle many connections concurrently. | ||
+ | |||
+ | Reading (Java implementations): | ||
* http://tutorials.jenkov.com/java-nio/nio-vs-io.html | * http://tutorials.jenkov.com/java-nio/nio-vs-io.html | ||
Sor 33: | Sor 51: | ||
- | {{tanszek:oktatas:informacios_rendszerek_integralasa:high_speed_socket.jpg|}} | + | {{tanszek:oktatas:informacios_rendszerek_integralasa:high_speed_socket.jpg?600|}} |
- | ===== Non-blocking loop ===== | + | ==== Non-blocking loop ==== |
<code java> | <code java> | ||
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); | ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); | ||
serverSocketChannel.socket().bind(new InetSocketAddress(9999)); | serverSocketChannel.socket().bind(new InetSocketAddress(9999)); | ||
- | serverSocketChannel.configureBlocking(false); // ez a sor jelzi a blokkolásmentes működést | + | serverSocketChannel.configureBlocking(false); // non blocking enabled |
while(true){ | while(true){ | ||
Sor 53: | Sor 71: | ||
- | |||
- | [[Java example for Blocking and Non-Blocking Socket]] | ||
- | |||
- | ** Exercise 1. ** | ||
- | |||
- | Create a simplified FTP (file transport) client and **blocking** server where the client can send or download text files from the server: | ||
- | |||
- | == General use-cases == | ||
- | -) Client connects to the server and sends a 'file listing' message | ||
- | -) Server sends back the list of the downloadable files | ||
- | -) Client lists the files and asks the user what action they want to take? Upload or download? ('u' or 'd') | ||
- | -) In both cases users must give the full file name with extension | ||
- | -) The client sends the selected file to the server (upload) or downloads the selected file from the server to a specific directory. | ||
- | |||
- | |||
- | == Server viewpoint == | ||
- | -) After connecting, it reads the files from the /store subdirectory and sends the file names to the client after receiving the listing message. | ||
- | -) We are waiting for the client's 'u' or 'd' operation | ||
- | -) We get a filename from the client and if the action is 'd' (download), we read the file content and return its contents | ||
- | -) If the operation is 'u' (upload), we open a new file with the specified name and wait for the data to be written to the file. | ||
- | |||
- | == Client viewpoint == | ||
- | |||
- | -) The client connects and waits for the list of files coming back and writes it to the console | ||
- | -) We ask for the "u" or "d" key | ||
- | -) Then we'll ask for the file-name as well. | ||
- | -) The client reads the files from the /files folder, or creates the downloaded file here | ||
- | -) If you press "d", it creates /files/ and writes data from the server | ||
- | -) If you press "u", /files/ is sent to the server | ||
- | |||
- | |||
- | ** Exercise 2. ** | ||
- | Modify the **non-blocking** code so that you can transfer a burned-in name and existing text or image file larger than 2 kbytes and verify that it was successfully sent. | ||