Opened 9 years ago

Closed 7 years ago

#788 closed enhancement (fixed)

I2CP per-message reliability setting

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.14
Component: api/i2cp Version: 0.9.3
Keywords: performance usability error logging Cc:
Parent Tickets: Sensitive: no


I2CP outbound message reliability setting (Guaranteed, BestEffort?, None) is now forced to none, was never used on the client side.

Now that we have per-message settings working well, restore the setting on a per-message basis (using one of the 7 bits remaining in DateAndFlags?). Add more failure codes in the MessageStatusMessage? response. Set the bit for SYN packets in streaming. Fail the socket on error received, with different IOEs.

This will allow a "fail-fast" on LeaseSet? lookup failure (15 sec like b32 works, instead of 60 sec now) and perhaps a better error page in HTTP proxy.

Also allows finer-grained messages and logging for more rare problems such as no tunnels.

All in all, a better user experience as lack of leaseset is a good indicator that the eepsite isn't up, rather than net congestion.


Change History (10)

comment:1 Changed 9 years ago by zzz

Summary: I2CP per-message reilability settingI2CP per-message reliability setting

comment:2 Changed 9 years ago by zzz

As of 0.9.4, the SendMessageMessage? nonce value of 0 means don't reply even when reliability != none. So we can use the opposite (nonce > 0 when reliability == none) to force a reply? Or we can burn a bit in the DateAndFlags? field. Or maybe we have to do both.

comment:3 Changed 9 years ago by zzz

Owner: set to zzz
Status: newaccepted

0.9.4-2 contains preliminary support for passing a specific failure code from OCMOSJ back to the client side of I2CP.

Haven't figured out how to get from there back to streaming. Right now we have no callback and no message ID returned to the sendMessage caller.

Probably going to have to add a new listener interface and yet another sendMessage call that specifies the listener and returns a message ID. It's also time to look at the rather unpleasant MessageState? again.

My idea is to request the callback only for SYN packets. If we get a failure, throw a particular type of IOE, so HTTP client can display a particular error page. Haven't thought through it completely yet.

comment:4 Changed 8 years ago by zzz


Added proposal to use bits 10 and 9 in the SendMessageExpiresMessage? flags: http://i2p-projekt.i2p/i2cp_spec

Last edited 7 years ago by zzz (previous) (diff)

comment:5 Changed 8 years ago by zzz

Related, or part 2: get the failure from streaming to the I2PSocket with unique exceptions, and from there to new HTTP Proxy error pages.

There's another case unrelated to I2CP - when streaming receives a RESET before any data:

12/03 xx:xx:53.609 DEBUG [nt Runner 63] .i2ptunnel.I2PTunnelHTTPClient: Client[1/257]: Destination: xxxxxxxxxxxx.i2p
12/03 xx:xx:53.609 INFO  [nt Runner 63] nnel.I2PTunnelHTTPClientRunner: I2PTunnelRunner started
12/03 xx:xx:53.612 DEBUG [elRunner 230] nnel.I2PTunnelHTTPClientRunner: Initial data 287 written to I2P, 0 written to the socket, starting forwarders
12/03 xx:xx:53.615 DEBUG [rder 230.459] nnel.I2PTunnelHTTPClientRunner: toI2P: Forwarding between xxxxxx and xxxxxx
12/03 xx:xx:53.615 DEBUG [rder 230.460] nnel.I2PTunnelHTTPClientRunner: fromI2P: Forwarding between xxxxxx and xxxxxx
12/03 xx:xx:57.962 WARN  [rder 230.460] nnel.I2PTunnelHTTPClientRunner: fromI2P: Error forwarding Input stream error
	at net.i2p.client.streaming.MessageInputStream.throwAnyError(
	at net.i2p.i2ptunnel.I2PTunnelRunner$
Caused by: Reset received
	at net.i2p.client.streaming.Connection.resetReceived(
	at net.i2p.client.streaming.ConnectionPacketHandler.verifyReset(
	at net.i2p.client.streaming.ConnectionPacketHandler.verifyPacket(
	at net.i2p.client.streaming.ConnectionPacketHandler.receivePacket(
	at net.i2p.client.streaming.PacketHandler.receiveKnownCon(
	at net.i2p.client.streaming.PacketHandler.receivePacketDirect(
	at net.i2p.client.streaming.PacketHandler.receivePacket(
	at net.i2p.client.streaming.MessageHandler.messageAvailable(
	at net.i2p.client.I2PSessionDemultiplexer.messageAvailable(
	at net.i2p.client.I2PSessionMuxedImpl$
12/03 xx:xx:57.962 INFO  [rder 230.460] nnel.I2PTunnelHTTPClientRunner: fromI2P: done forwarding between xxxxxx and xxxxxx
12/03 xx:xx:57.962 INFO  [rder 230.460] nnel.I2PTunnelHTTPClientRunner: fromI2P: not closing so we can write the error message
12/03 xx:xx:57.963 DEBUG [elRunner 230] nnel.I2PTunnelHTTPClientRunner: At least one forwarder completed, closing and joining
12/03 xx:xx:57.963 DEBUG [elRunner 230] nnel.I2PTunnelHTTPClientRunner: runner has a timeout job, totalReceived = 0 totalSent = 0 job = net.i2p.i2ptunnel.I2PTunnelHTTPClient$OnTimeout@206f80
12/03 xx:xx:57.964 INFO  [rder 230.459] nnel.I2PTunnelHTTPClientRunner: toI2P: done forwarding between xxxxxx and xxxxxx

… and proxy then sends the standard "eepsite unreachable" error page, which is misleading. We may wish to mimic the language firefox uses on its error page for resets.

Look into the specific exceptions that extend that we can use. We could also add some of our own if necessary.

comment:6 Changed 8 years ago by zzz

As an example to fix the above, Java uses Connection reset. We could create e.g. ConnectionResetException? extends SocketException? and throw that. Then catch in i2ptunnel to display a unique error page.

Do this a dozen times to have unique error pages for each possible problem.

comment:7 Changed 7 years ago by zzz


comment:8 Changed 7 years ago by zzz

SendMessageOptions? and router-side returning of nonce back to the client in the MessageStatusMessage? in i2p.i2p.zzz.test2.

Client-side is much harder. Need a new listener (can't change existing listeners) and a new I2PSession.sendMessage() method that returns a nonce. MessageStatusMessageHandler? must call the new listener asynchronously. Streaming.PacketQueue? must keep a mapping from nonce back to the Connection and MessageOutputStream?. Somehow.

comment:9 Changed 7 years ago by str4d

Keywords: performance usability error logging added
Milestone: 0.9.14

comment:10 Changed 7 years ago by zzz

Milestone: 0.9.14
Resolution: fixed
Status: acceptedclosed

All finished in 0.9.14

Note: See TracTickets for help on using tickets.