Seems still does not solve the problem on the Windows platform

[xmh0511]

As seen in the picture, I used the latest one in the github, and the first problem in #27 remains unchanged.

2024-03-28.11.44.01.mov

[xmh0511]

It seems that 437ef17 fix the issue, however, the subsequent commit re-introduces the issue.

[SajjadPourali]

It seems that 437ef17 fix the issue, however, the subsequent commit re-introduces the issue.

True, as I mentioned in the comment on #27 (comment), you need to manually shut down the stream yourself by calling stream.shutdown().await. I previously implemented auto shutdown when the stream dropped, but since Rust's drop does not support async, I used task::block_in_place that dramatically affects memory allocation and recursion. In other words, until finding a way to implement the drop asynchronously, you need to manually shutdown the stream yourself when a timeout reached.

[SajjadPourali]

Another solution is resetting the connection.

impl Drop for IpStackTcpStream {
    fn drop(&mut self) {
        if let Ok(p) = self.create_rev_packet(RST | ACK, TTL, None, Vec::new()) {
            _ = self.packet_sender.send(p);
        }
        if let Ok(p) = self.create_rev_packet(NON, DROP_TTL, None, Vec::new()) {
            _ = self.packet_sender.send(p);
        }
    }
}

[xmh0511]

Another solution is resetting the connection.

impl Drop for IpStackTcpStream {
    fn drop(&mut self) {
        if let Ok(p) = self.create_rev_packet(RST | ACK, TTL, None, Vec::new()) {
            _ = self.packet_sender.send(p);
        }
        if let Ok(p) = self.create_rev_packet(NON, DROP_TTL, None, Vec::new()) {
            _ = self.packet_sender.send(p);
        }
    }
}

We could investigate how the standard library or tokio resolves this issue when dropping the instance.

###Update

The tcpstream in tokio shutdown the connection after dropping(i.e. it does not reset the connection).

[xmh0511]

@SajjadPourali

Shall we wrapper the IpstackTcpStream in a Guard-like struct with the Option<IpstackTcpStream> field as its inner instance, and every time the drop of Guard-like struct is invoked, we take out the field and send it through a channel to a specific task that is used to shutdown the inner IpstackTcpStream?

The Guard-like struct behaves like a IpstackTcpStream, that is, read, write, flush, and shutdown are proxied to its inner IpstackTcpStream.

Pseudo-code:

struct TcpStream{
   inner: Option<IpstackTcpStream>,
   sender: Sender
}
impl Drop for TcpStream{
    fn drop(& mut self){
     if let Some(inner)  = self.inner.take(){
        self.sender.send(inner);
    }
   }
}
// Shutdown factory
  while let Some(ipstack_stream) = receive.recv(){
     tokio::spawn(async move {
        ipstack_stream.shutdown().await;
    })
  }

[SajjadPourali]

We could investigate how the standard library or tokio resolves this issue when dropping the instance.

###Update

The tcpstream in tokio shutdown the connection after dropping(i.e. it does not reset the connection).

The operating system is responsible for managing the TCP/IP stack, and neither Tokio nor Rust has control over it.

[xmh0511]

Ipstack is that an "operating system", see this approach in #31 (comment), is it available?

[xmh0511]

It seems that the shutdown of IpstackTcpStream still has some issues.

Not sure whether it's the issue of curl on the Windows platform.

[xmh0511]

#32

[SajjadPourali]

#33