2019-03-18 10:55:06 +00:00
|
|
|
// Copyright (C) 2019 Storj Labs, Inc.
|
|
|
|
// See LICENSE for copying information.
|
|
|
|
|
|
|
|
package orders_test
|
|
|
|
|
|
|
|
import (
|
|
|
|
"testing"
|
2019-07-02 17:06:12 +01:00
|
|
|
"time"
|
2019-03-18 10:55:06 +00:00
|
|
|
|
|
|
|
"github.com/google/go-cmp/cmp"
|
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
|
2019-12-27 11:48:47 +00:00
|
|
|
"storj.io/common/identity/testidentity"
|
|
|
|
"storj.io/common/pb"
|
|
|
|
"storj.io/common/signing"
|
|
|
|
"storj.io/common/storj"
|
|
|
|
"storj.io/common/testcontext"
|
|
|
|
"storj.io/common/testrand"
|
2019-03-18 10:55:06 +00:00
|
|
|
"storj.io/storj/storagenode"
|
|
|
|
"storj.io/storj/storagenode/orders"
|
2020-10-01 23:52:22 +01:00
|
|
|
"storj.io/storj/storagenode/orders/ordersfile"
|
2019-03-18 10:55:06 +00:00
|
|
|
"storj.io/storj/storagenode/storagenodedb/storagenodedbtest"
|
|
|
|
)
|
|
|
|
|
2019-07-19 18:40:27 +01:00
|
|
|
func TestDB(t *testing.T) {
|
2020-01-20 14:56:12 +00:00
|
|
|
storagenodedbtest.Run(t, func(ctx *testcontext.Context, t *testing.T, db storagenode.DB) {
|
2019-03-18 10:55:06 +00:00
|
|
|
ordersdb := db.Orders()
|
|
|
|
|
2019-04-08 19:15:19 +01:00
|
|
|
storagenode := testidentity.MustPregeneratedSignedIdentity(0, storj.LatestIDVersion())
|
2019-03-18 10:55:06 +00:00
|
|
|
|
2019-04-08 19:15:19 +01:00
|
|
|
satellite0 := testidentity.MustPregeneratedSignedIdentity(1, storj.LatestIDVersion())
|
2019-03-18 10:55:06 +00:00
|
|
|
|
|
|
|
piece := storj.NewPieceID()
|
|
|
|
|
|
|
|
// basic test
|
2019-03-21 13:24:26 +00:00
|
|
|
emptyUnsent, err := ordersdb.ListUnsent(ctx, 100)
|
2019-03-18 10:55:06 +00:00
|
|
|
require.NoError(t, err)
|
2019-03-21 13:24:26 +00:00
|
|
|
require.Len(t, emptyUnsent, 0)
|
|
|
|
|
|
|
|
emptyArchive, err := ordersdb.ListArchived(ctx, 100)
|
|
|
|
require.NoError(t, err)
|
|
|
|
require.Len(t, emptyArchive, 0)
|
2019-03-18 10:55:06 +00:00
|
|
|
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
now := time.Now()
|
|
|
|
before := now.Add(-time.Second)
|
2019-03-18 10:55:06 +00:00
|
|
|
|
2019-07-11 21:51:40 +01:00
|
|
|
piecePublicKey, piecePrivateKey, err := storj.NewPieceKey()
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
2020-10-01 23:52:22 +01:00
|
|
|
infos := make([]*ordersfile.Info, 2)
|
2019-08-16 15:53:22 +01:00
|
|
|
for i := 0; i < len(infos); i++ {
|
|
|
|
|
|
|
|
serialNumber := testrand.SerialNumber()
|
|
|
|
limit, err := signing.SignOrderLimit(ctx, signing.SignerFromFullIdentity(satellite0), &pb.OrderLimit{
|
|
|
|
SerialNumber: serialNumber,
|
|
|
|
SatelliteId: satellite0.ID,
|
|
|
|
UplinkPublicKey: piecePublicKey,
|
|
|
|
StorageNodeId: storagenode.ID,
|
|
|
|
PieceId: piece,
|
|
|
|
Limit: 100,
|
|
|
|
Action: pb.PieceAction_GET,
|
2020-04-30 13:00:06 +01:00
|
|
|
OrderCreation: before.AddDate(0, 0, -1),
|
|
|
|
PieceExpiration: before,
|
|
|
|
OrderExpiration: before,
|
2019-08-16 15:53:22 +01:00
|
|
|
})
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
order, err := signing.SignUplinkOrder(ctx, piecePrivateKey, &pb.Order{
|
|
|
|
SerialNumber: serialNumber,
|
|
|
|
Amount: 50,
|
|
|
|
})
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
2020-10-01 23:52:22 +01:00
|
|
|
infos[i] = &ordersfile.Info{
|
2019-08-16 15:53:22 +01:00
|
|
|
Limit: limit,
|
|
|
|
Order: order,
|
|
|
|
}
|
2019-03-19 18:30:27 +00:00
|
|
|
}
|
2019-03-18 10:55:06 +00:00
|
|
|
|
|
|
|
// basic add
|
2019-08-16 15:53:22 +01:00
|
|
|
err = ordersdb.Enqueue(ctx, infos[0])
|
2019-03-18 10:55:06 +00:00
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
// duplicate add
|
2019-08-16 15:53:22 +01:00
|
|
|
err = ordersdb.Enqueue(ctx, infos[0])
|
2019-03-18 10:55:06 +00:00
|
|
|
require.Error(t, err, "duplicate add")
|
|
|
|
|
|
|
|
unsent, err := ordersdb.ListUnsent(ctx, 100)
|
|
|
|
require.NoError(t, err)
|
2020-10-01 23:52:22 +01:00
|
|
|
require.Empty(t, cmp.Diff([]*ordersfile.Info{infos[0]}, unsent, cmp.Comparer(pb.Equal)))
|
2019-08-16 15:53:22 +01:00
|
|
|
|
|
|
|
// Another add
|
|
|
|
err = ordersdb.Enqueue(ctx, infos[1])
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
unsent, err = ordersdb.ListUnsent(ctx, 100)
|
|
|
|
require.NoError(t, err)
|
|
|
|
require.Empty(t,
|
2020-10-01 23:52:22 +01:00
|
|
|
cmp.Diff([]*ordersfile.Info{infos[0], infos[1]}, unsent, cmp.Comparer(pb.Equal)),
|
2019-08-16 15:53:22 +01:00
|
|
|
)
|
2019-03-21 13:24:26 +00:00
|
|
|
|
|
|
|
// list by group
|
|
|
|
unsentGrouped, err := ordersdb.ListUnsentBySatellite(ctx)
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
2020-10-15 19:57:02 +01:00
|
|
|
expectedGrouped := map[storj.NodeID][]*ordersfile.Info{}
|
2019-03-21 13:24:26 +00:00
|
|
|
require.Empty(t, cmp.Diff(expectedGrouped, unsentGrouped, cmp.Comparer(pb.Equal)))
|
|
|
|
|
|
|
|
// test archival
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
archivedAt := time.Now()
|
2019-08-22 15:33:14 +01:00
|
|
|
err = ordersdb.Archive(ctx, archivedAt, orders.ArchiveRequest{
|
2019-08-16 15:53:22 +01:00
|
|
|
Satellite: satellite0.ID,
|
|
|
|
Serial: infos[0].Limit.SerialNumber,
|
|
|
|
Status: orders.StatusAccepted,
|
|
|
|
})
|
2019-03-21 13:24:26 +00:00
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
// duplicate archive
|
2019-08-22 15:33:14 +01:00
|
|
|
err = ordersdb.Archive(ctx, archivedAt, orders.ArchiveRequest{
|
2019-08-16 15:53:22 +01:00
|
|
|
Satellite: satellite0.ID,
|
|
|
|
Serial: infos[0].Limit.SerialNumber,
|
|
|
|
Status: orders.StatusRejected,
|
|
|
|
})
|
|
|
|
require.Error(t, err)
|
|
|
|
require.True(t,
|
|
|
|
orders.OrderNotFoundError.Has(err),
|
|
|
|
"expected orders.OrderNotFoundError class",
|
|
|
|
)
|
|
|
|
|
|
|
|
// one new archive and one duplicated
|
2019-08-22 15:33:14 +01:00
|
|
|
err = ordersdb.Archive(ctx, archivedAt, orders.ArchiveRequest{
|
2019-08-16 15:53:22 +01:00
|
|
|
Satellite: satellite0.ID,
|
|
|
|
Serial: infos[0].Limit.SerialNumber,
|
|
|
|
Status: orders.StatusRejected,
|
|
|
|
}, orders.ArchiveRequest{
|
|
|
|
Satellite: satellite0.ID,
|
|
|
|
Serial: infos[1].Limit.SerialNumber,
|
|
|
|
Status: orders.StatusRejected,
|
|
|
|
})
|
2019-03-21 13:24:26 +00:00
|
|
|
require.Error(t, err)
|
2019-08-16 15:53:22 +01:00
|
|
|
require.True(t,
|
|
|
|
orders.OrderNotFoundError.Has(err),
|
|
|
|
"expected ErrUnsentOrderNotFoundError class",
|
|
|
|
)
|
2019-03-21 13:24:26 +00:00
|
|
|
|
|
|
|
// shouldn't be in unsent list
|
|
|
|
unsent, err = ordersdb.ListUnsent(ctx, 100)
|
|
|
|
require.NoError(t, err)
|
|
|
|
require.Len(t, unsent, 0)
|
|
|
|
|
|
|
|
// it should now be in the archive
|
|
|
|
archived, err := ordersdb.ListArchived(ctx, 100)
|
|
|
|
require.NoError(t, err)
|
2019-08-16 15:53:22 +01:00
|
|
|
require.Len(t, archived, 2)
|
2019-03-21 13:24:26 +00:00
|
|
|
|
|
|
|
require.Empty(t, cmp.Diff([]*orders.ArchivedInfo{
|
|
|
|
{
|
2019-08-16 15:53:22 +01:00
|
|
|
Limit: infos[0].Limit,
|
|
|
|
Order: infos[0].Order,
|
2019-03-21 13:24:26 +00:00
|
|
|
|
|
|
|
Status: orders.StatusAccepted,
|
|
|
|
ArchivedAt: archived[0].ArchivedAt,
|
|
|
|
},
|
2019-08-16 15:53:22 +01:00
|
|
|
{
|
|
|
|
Limit: infos[1].Limit,
|
|
|
|
Order: infos[1].Order,
|
|
|
|
|
|
|
|
Status: orders.StatusRejected,
|
|
|
|
ArchivedAt: archived[1].ArchivedAt,
|
|
|
|
},
|
2019-03-21 13:24:26 +00:00
|
|
|
}, archived, cmp.Comparer(pb.Equal)))
|
|
|
|
|
2020-04-30 13:00:06 +01:00
|
|
|
time.Sleep(time.Second)
|
|
|
|
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
// archived order should not be deleted because they are not 1 hour old
|
|
|
|
n, err := db.Orders().CleanArchive(ctx, now.Add(-time.Hour))
|
2019-08-15 17:56:33 +01:00
|
|
|
require.NoError(t, err)
|
|
|
|
require.Equal(t, 0, n)
|
|
|
|
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
// archived order should be deleted because they are archived before 1 second later
|
|
|
|
n, err = db.Orders().CleanArchive(ctx, archivedAt.Add(time.Second))
|
2019-08-15 17:56:33 +01:00
|
|
|
require.NoError(t, err)
|
2019-08-16 15:53:22 +01:00
|
|
|
require.Equal(t, 2, n)
|
2019-03-18 10:55:06 +00:00
|
|
|
})
|
|
|
|
}
|
2019-07-19 18:40:27 +01:00
|
|
|
|
|
|
|
func TestDB_Trivial(t *testing.T) {
|
2020-01-20 14:56:12 +00:00
|
|
|
storagenodedbtest.Run(t, func(ctx *testcontext.Context, t *testing.T, db storagenode.DB) {
|
2019-07-19 18:40:27 +01:00
|
|
|
satelliteID, serial := testrand.NodeID(), testrand.SerialNumber()
|
|
|
|
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
now := time.Now()
|
|
|
|
before := now.Add(-time.Second)
|
2020-04-30 13:00:06 +01:00
|
|
|
|
2019-07-19 18:40:27 +01:00
|
|
|
{ // Ensure Enqueue works at all
|
2020-10-01 23:52:22 +01:00
|
|
|
err := db.Orders().Enqueue(ctx, &ordersfile.Info{
|
2019-07-19 18:40:27 +01:00
|
|
|
Order: &pb.Order{},
|
|
|
|
Limit: &pb.OrderLimit{
|
|
|
|
SatelliteId: satelliteID,
|
|
|
|
SerialNumber: serial,
|
2020-04-30 13:00:06 +01:00
|
|
|
OrderExpiration: before,
|
2019-07-19 18:40:27 +01:00
|
|
|
},
|
|
|
|
})
|
|
|
|
require.NoError(t, err)
|
|
|
|
}
|
|
|
|
|
|
|
|
{ // Ensure ListUnsent works at all
|
2019-08-13 20:08:05 +01:00
|
|
|
infos, err := db.Orders().ListUnsent(ctx, 1)
|
2019-07-19 18:40:27 +01:00
|
|
|
require.NoError(t, err)
|
2019-08-13 20:08:05 +01:00
|
|
|
require.Len(t, infos, 1)
|
2019-07-19 18:40:27 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
{ // Ensure ListUnsentBySatellite works at all
|
2019-08-13 20:08:05 +01:00
|
|
|
infos, err := db.Orders().ListUnsentBySatellite(ctx)
|
2019-07-19 18:40:27 +01:00
|
|
|
require.NoError(t, err)
|
2020-10-15 19:57:02 +01:00
|
|
|
require.Len(t, infos, 0)
|
2019-07-19 18:40:27 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
{ // Ensure Archive works at all
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
err := db.Orders().Archive(ctx, before, orders.ArchiveRequest{satelliteID, serial, orders.StatusAccepted})
|
2019-07-19 18:40:27 +01:00
|
|
|
require.NoError(t, err)
|
|
|
|
}
|
|
|
|
|
|
|
|
{ // Ensure ListArchived works at all
|
2019-08-13 20:08:05 +01:00
|
|
|
infos, err := db.Orders().ListArchived(ctx, 1)
|
2019-07-19 18:40:27 +01:00
|
|
|
require.NoError(t, err)
|
2019-08-13 20:08:05 +01:00
|
|
|
require.Len(t, infos, 1)
|
2019-07-19 18:40:27 +01:00
|
|
|
}
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
|
2019-08-15 17:56:33 +01:00
|
|
|
{ // Ensure CleanArchive works at all
|
storagenode: live tracking of order window usage
This change accomplishes multiple things:
1. Instead of having a max in flight time, which means
we effectively have a minimum bandwidth for uploads
and downloads, we keep track of what windows have
active requests happening in them.
2. We don't double check when we save the order to see if it
is too old: by then, it's too late. A malicious uplink
could just submit orders outside of the grace window and
receive all the data, but the node would just not commit
it, so the uplink gets free traffic. Because the endpoints
also check for the order being too old, this would be a
very tight race that depends on knowledge of the node system
clock, but best to not have the race exist. Instead, we piggy
back off of the in flight tracking and do the check when
we start to handle the order, and commit at the end.
3. Change the functions that send orders and list unsent
orders to accept a time at which that operation is
happening. This way, in tests, we can pretend we're
listing or sending far into the future after the windows
are available to send, rather than exposing test functions
to modify internal state about the grace period to get
the desired effect. This brings tests closer to actual
usage in production.
4. Change the calculation for if an order is allowed to be
enqueued due to the grace period to just look at the
order creation time, rather than some computation involving
the window it will be in. In this way, you can easily
answer the question of "will this order be accepted?" by
asking "is it older than X?" where X is the grace period.
5. Increases the frequency we check to send up orders to once
every 5 minutes instead of once every hour because we already
have hour-long buffering due to the windows. This decreases
the maximum latency that an order will be reported back to
the satellite by 55 minutes.
Change-Id: Ie08b90d139d45ee89b82347e191a2f8db1b88036
2020-08-12 20:01:43 +01:00
|
|
|
n, err := db.Orders().CleanArchive(ctx, now)
|
2019-08-15 17:56:33 +01:00
|
|
|
require.NoError(t, err)
|
|
|
|
require.Equal(t, 1, n)
|
|
|
|
}
|
2019-07-19 18:40:27 +01:00
|
|
|
})
|
|
|
|
}
|