[Question]: SetContext has no effect in UDP. Is it intentionally designed this way?

[ckcfcc]

Actions I've taken before I'm here

• I've thoroughly read the documentations about this problem but still have no answer.
• I've searched the Github Issues/Discussions but didn't find any similar problems that have been solved.
• I've searched the internet for this problem but didn't find anything helpful.

Questions with details

在UDP中，只有OnTraffic会生效，所以我用OnTraffic的参数conn来标识一个UDP客户端，但是使用中发现即使是不同的物理机发起数据表，每次再次进入OnTraffic的conn.Context() 得到的结果都是nil。

我进一步学习了OnTraffic的源代码调用，发现每次的conn在触发OnTraffic都会被释放。感觉是故意为之。

请问是否能否有办法，让一个同源的udp客户端连接后固定分配一个conn对象而不释放，这样context才有更多的用处，否则，使用时还要自己再设计一个封装来更具remoteAddr来确定一个连接信息来绑定 context，感觉有点多此一举。 希望gnet中就能提供这样的功能，对于同源(同一个remoteAddr)来说使用同一个conn。

可以提供一个超时机制设置，比如多时间后，这个客户端没有发送和收任何数据包，就标记为已经废弃或者回收掉。

不知是否可行？

这个issue好像和 UDP with unique fds for each "connection"有点类似，但是那个issue好像是主要强调唯一性，这个主要是想在udp的conn上使用conn.Context()

Code snippets (optional)

No response

[panjf2000]

因为 UDP 是基于报文而非连接，所以 conn 对于 UDP 来说只是一层抽象，用来和 TCP 或 Unix 保持 API 兼容而已，这个 context 是连接级别的，UDP 的服务端通常没有连接的概念，所以 context 在 UDP 中也就不会持久化保存。

[gh-translator]

🤖 Non-English text detected, translating...

---

Because UDP is based on messages rather than connections, conn is just a layer of abstraction for UDP, used to maintain API compatibility with TCP or Unix. This context is at the connection level. UDP servers usually have no concept of connections, so The context will not be persisted in UDP.

[panjf2000]

可以提供一个超时机制设置，比如多时间后，这个客户端没有发送和收任何数据包，就标记为已经废弃或者回收掉。

实现肯定可以这么实现，把用户层的 map 移到 gnet 内部再加上超时机制，问题是引入这个复杂性感觉代价不小，我在想有没有必要，毕竟这好像是第一次有人提出这种类似的需求。

[gh-translator]

🤖 Non-English text detected, translating...

---

You can provide a timeout mechanism setting. For example, after a long period of time, if the client does not send or receive any data packets, it will be marked as abandoned or recycled.

The implementation can definitely be implemented like this, moving the user layer map inside gnet and adding a timeout mechanism. The problem is that introducing this complexity feels expensive. I wonder if it is necessary. After all, this seems to be the first time someone has proposed this. Similar needs.

[lesismal]

而非连接，所以 conn 对于 UDP 来说只是一层抽象，用来和 TCP 或 Unix 保持 API 兼容而已，这个 context 是连接级别的，UDP 的服务

我的udp实现里, 从最初就支持了OnOpen/OnData/OnClose, 支持了超时, 超时自动Close, 而且框架内自己保持了udp socket的map映射, 每次传递给用户的都是同一个*Conn, 不会像标准库一样每次数据传递不同的结构体指针, 比标准库方便多了, 给用户省掉麻烦.

另外, 就像之前其他issue里有人提过的, SetDeadline算是个挺基础的功能了, 框架不支持, 都让用户手撸确实有点虐

[gh-translator]

🤖 Non-English text detected, translating ...

---

rather than a connection, so conn is just a layer of abstraction for UDP, used to maintain API compatibility with TCP or Unix. This context is a connection-level, UDP service

In my udp implementation, OnOpen/OnData/OnClose has been supported from the beginning, and it has supported timeout and automatic close after timeout. Moreover, the framework maintains the map mapping of udp socket, and the same *Conn is passed to the user every time. It does not transfer different structure pointers for each data like the standard library, which is much more convenient than the standard library and saves users trouble.

In addition, as someone mentioned in other previous issues, SetDeadline is a very basic function. The framework does not support it, so it is really a bit cruel for users to do it by hand.

[github-actions]

This issue is marked as stale because it has been open for 30 days with no activity.

You should take one of the following actions:

• Manually close this issue if it is no longer relevant
• Comment if you have more information to share

This issue will be automatically closed in 7 days if no further activity occurs.