Retrieve status info already returns the data. It is wired to the named unbundler at the bottom of the loop. It unbundles the Camera IP and robot IP, but not the other fields. If you grow it, or change robot IP, you can retrieve the event info cluster.
The picture you posted is of the implementation details. That is a constant that sets the feedback node storage the first time it executes. The TCP message shows up occasionally and is held onto by the shift register so that once seen, the return value remains valid.
The new or cached value is then passed by wire, not local variable, to a loop that processes a stream of mixed info. The 10,000 bytes is a max read, by the way.
As for sending to the robot, I'd just write this info to a network table variable. There is no need to make your own TCP connection for about ten bytes of data.
Port 1741: This is communicated on a local connection between the DS and DB. It is on the same computer 99% of the time, and if you are using two computers, it doesn't go through the field either, just between your computers. So the port is unlikely to be blocked. If it is, very little of the DB works already.
The info is not documented, but not cryptic either. The name will be some characters. It is short and understandable event name, but not a complete address or anything. Type will tell you what type of match it was. Number, the match number. Replay will increment if this is a replay of a previous match. I don't want to spoil all the decoding fun...
This data shows up in the log file viewer as the Qual 3-1, for example.
And bear in mind that this wasn't well tested. I expect it to work, and it was put there for this purpose, but to my knowledge hasn't been used yet. It's just like those special feature on your robot that "work" when you talk to other teams and judges, they just haven't been tested on the field

.
Greg McKaskle