A kiválasztott változat és az aktuális verzió közötti különbségek a következők.
Következő változat | Előző változat | ||
tanszek:oktatas:iss_t:integration_based_on_tcp_ip_sockets [2023/03/05 16:35] knehez létrehozva |
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 24: | Sor 24: | ||
* Where the number of transactions per second up to ~ 50 transactions, there should have been applied. (20ms / sec transfer) | * Where the number of transactions per second up to ~ 50 transactions, there should have been applied. (20ms / sec transfer) | ||
+ | ==== Blocking and non-blocking TCP sockets in Java ==== | ||
+ | {{:tanszek:oktatas:iss_t:sockets-blocking-nonblocking.png?800|}} | ||
- | [[Java example for Blocking and Non-Blocking Socket]] | + | 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: |
- | ** Exercise 1. ** | + | === Blocking sockets === |
- | Create a simplified FTP (file transport) client and **blocking** server where the client can send or download text files from the server: | + | **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. |
- | == General use-cases == | + | **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. |
- | -) 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. | + | |
+ | **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//. | ||
- | == Server viewpoint == | + | === Non-Blocking sockets === |
- | -) 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 == | + | **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. |
- | -) The client connects and waits for the list of files coming back and writes it to the console | + | **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. |
- | -) We ask for the "u" or "d" key | + | |
- | -) Then we'll ask for the file-name as well. | + | **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. |
- | -) 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 | + | Reading (Java implementations): |
- | -) If you press "u", /files/ is sent to the server | + | |
+ | * http://tutorials.jenkov.com/java-nio/nio-vs-io.html | ||
+ | * http://www.javaworld.com/article/2073344/core-java/use-select-for-high-speed-networking.html | ||
+ | |||
+ | |||
+ | {{tanszek:oktatas:informacios_rendszerek_integralasa:high_speed_socket.jpg?600|}} | ||
+ | |||
+ | |||
+ | ==== Non-blocking loop ==== | ||
+ | <code java> | ||
+ | ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); | ||
+ | |||
+ | serverSocketChannel.socket().bind(new InetSocketAddress(9999)); | ||
+ | serverSocketChannel.configureBlocking(false); // non blocking enabled | ||
+ | |||
+ | while(true){ | ||
+ | SocketChannel socketChannel = serverSocketChannel.accept(); | ||
+ | |||
+ | if(socketChannel != null){ | ||
+ | // the connection is accepted | ||
+ | } | ||
+ | } | ||
+ | </code> | ||
- | ** 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. | ||