quic-s/quics-protocol

Simple protocol for QUIC-S based on QUIC protocol

quics-protocol's Issues

The problem of not being able to distinguish between Dial and DialWithTransaction in Listen

Is your feature request related to a problem? Please describe.
There is a DialWithTransaction that opens a transaction at the same time as the dial so that you can handle features like security authorization when you first dial the protocol. However, currently, the listener cannot distinguish between Dial and DialWithTransaction because it only uses one listen method. In this case, the client should use DialWithTransaction for security authorization, but the connection is established even if the client approaches with Dial.

Describe the solution you'd like
To solve the above problem, we could consider adding a ListenWithTransaction to pair with DialWithTransaction, or getting rid of DialWithTransaction and adding a security authorization to the connhandler in Listen.

Additional context
For now, I think it would be a good idea to add ListenWithTransaction to prevent the conn object from being returned if the transaction does not succeed.

Add more protocol message types

Is your feature request related to a problem? Please describe.
Currently, there are only two types of protocols: message transmission and []byte type file transmission.
Therefore, it is necessary to add protocol message types and methods to conveniently handle more diverse communications.

Describe the solution you'd like
It is possible that this will be modified during the implementation phase, but for now, we are thinking about adding authentication when establishing a connection for the first time, adding a message in the form of a text, and sending additional information about the file when sending it.

Describe alternatives you've considered

Additional context

There is a problem with a segmentation fault error occurring when the connection is broken and the structure becomes nil

Describe the bug
This is not a problem that occurs often, but when multiple tasks are performed in parallel and the connection is disconnected, a segmentation fault error may occur because the connection struct is nil when the open transaction method is called.

We need to check whether the connection struct is nil.

To Reproduce
Occurs when testing a situation where the connection is disconnected several times.

Improved to allow input of domain name when dialing

Is your feature request related to a problem? Please describe.
Currently, you can only enter the exact IP address, but it would be more convenient to use if you could also access the domain name.

Describe the solution you'd like
Implemented using the lookup method of the net package

Improve the protocol to use Stream.

Is your feature request related to a problem? Please describe.

Current versions of the protocol create just one stream to send and receive all messages and files.
However, this can lead to head of line blocking issues and does not properly utilize quic's new stream feature.
Since one of QUIC's strengths is the ability to implement parallel connections using STREAMs, it needs to be improved to allow for parallel use of STREAMs.

Describe the solution you'd like

Currently, we implement the transfer of data using a connection struct, but we add a stream struct. We then change it so that the user can do the OpenTransaction first using the connection struct and then call the data transfer method using the stream struct.
This sending and receiving communication over a single stream is called a transaction, and it allows for several to be performed in parallel at once.
If you change it as above, you can ping-pong while sending and receiving data in one stream, so delete the ~WithResponse method.

Describe alternatives you've considered

Additional context

https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/

Problems when there are changes to the file during file transfer

Is your feature request related to a problem? Please describe.
In the current structure, changes to the file are not properly detected while the file is being transmitted using the SendFile method. In this case, there is a potential risk because the contents of the transmitted file may be contaminated.

Describe the solution you'd like
I think we need to add a process to check if anything has changed during file transfer by checking the ModTime before and after actually transferring the file.

Additional context
Checking the hash based on the file contents may be the most reliable method, but I am concerned that it may take a long time to check the hash for large files.