有时数据包只有在进程结束后才传输? [Java]

发布于 2024-08-14 02:53:31 字数 224 浏览 4 评论 0原文

我有一个应用程序,它打开一个数据报套接字并发送到各种其他进程......有时这个应用程序启动另一个进程(使用 ProcessBuilder),它也进行一些网络通信......

现在,笑话是,启动的进程“有时会” “仅在主应用程序终止后才收到消息...或者有时它会发送到 X,但它们只会在主应用程序停止时才会发送...

我不知道发生了什么...任何人都知道听说过这样的事情吗?仅当进程停止时才传输数据包?

I have an application which opens a datagram sockets and sends to various other processes .... sometimes this application lauches another process (using ProcessBuilder) which also does some network communication...

Now, the joke is, the launched process will "sometimes" only recieve messages after the main application is terminated ... OR sometimes it will send to X but they will only be delivered when the main application is stopped...

I've got no clue what is going on ... anyone ever hear of something like this? Packets only being transmitted when a process is stopped?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

许一世地老天荒 2024-08-21 02:53:31

我使用 Java 套接字进行编程已经有一段时间了,但我确实记得您必须显式刷新套接字才能“强制”发送所有数据。这将在为您关闭套接字时完成,这将解释您观察到的行为。

It's been a while that I've been programming with sockets in Java, but I do remember that you have to explicitly flush a socket to "force" all data to be send. This will be done upon closing the socket for you, which would explain your observed behaviour.

长发绾君心 2024-08-21 02:53:31

你看过socket.setTcpNoDelay(true);吗?

这是一种优化,等待收集一定数量的数据,然后再通过网络发送数据。对于发送零星和少量数据的应用程序,应将其设置为关闭。

编辑:
抱歉,我认为这仅适用于非数据报套接字。可能不是你的问题。

Have you looked at socket.setTcpNoDelay(true);?

This is an optimization that waits for a certain amount of data to collect before it sends it over the network. For applications sending sporadic and small amounts of data, this should be set to off.

EDIT:
Sorry, I think this is only for non-datagram sockets. Probably not your problem.

岁吢 2024-08-21 02:53:31

子进程正在写入 System.outSystem.err 吗?您是否已设置主进程在子进程启动后耗尽这些流?可能是子进程只是在尝试在未被读取的阻塞流上打印日志消息时陷入僵局。当父应用程序被终止时,流将被解除阻塞,所有内容都会重新开始移动。这可能是一个渺茫的机会,但在启动我总是检查的子进程时,我已经被它咬住了足够多的次数。

Is the child process writing to System.out or System.err? Have you set up the main process to drain those streams once the child process is started? It could be that the child process is just deadlocked trying to print a log message on a blocking stream that isn't being read. When the parent app is killed, the stream gets unblocked and everything starts moving again. It may be a longshot, but I've been bitten by it enough times when starting child processes that I always check.

仲春光 2024-08-21 02:53:31

一种可能性是这是使用数据报的结果。数据报本质上是不可靠的,数据包可能会被丢弃或乱序传送。

您的应用程序也可能终止得太快。应用程序和启动的进程是否进行握手以确保它们都知道何时关闭?

编辑:

但实际上,我认为最可能的原因是子进程阻塞,因为父进程不读取写入子进程输出的内容......直到
现在已经太晚了,无所谓了。作为实验,将以下内容添加到子进程启动中:

OutputStream os = new FileOutputStream(...); // pick a suitable temp filename
System.setOut(os);
System.setErr(os);

如果此 hack 解决了问题,则明确表明这是根本问题。

One possibility is that this is a result of using datagrams. Datagrams are inherently unreliable with the possibility that packets may be dropped or delivered out of order.

It is also possible that your application is just terminating too quickly. Do the application and the launched process do a handshake to ensure that they both know when to shut down?

EDIT:

But actually, I think that the most likely cause is that the child process is blocking because the parent process does not read stuff written to the child's output ... until
it it is too late to matter. As an experiment, add the following to the child process startup:

OutputStream os = new FileOutputStream(...); // pick a suitable temp filename
System.setOut(os);
System.setErr(os);

If this hack fixes things, it is a sure sign that this is the root problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文