{packet, 4}

Andreas Schultz andreas.schultz@REDACTED
Fri Apr 17 12:05:09 CEST 2020


Am Fr., 17. Apr. 2020 um 11:50 Uhr schrieb Roberto Ostinelli <
ostinelli@REDACTED>:

> All,
> Hope you are safe and well.
>
> This is probably a stupid question and I probably need more coffe, but...
> if I use {packet, 4} as a transport option on a server that uses a binary
> protocol, it means that it might wait for up to 256^4 so 4,294,967,296
> bytes of data. If I'm not mistaken, then this could be an easy target for
> DDoS attacks (client are not necessarily well-known).
>

{packet, 4} means that your payload is prefixed with a 4 byte integer in
network byte ordering that gives the length of the following payload data.
Any data that is sent gets this length field prepended and for received
data it is expected to be there. I don't think that is what you want?

Unfortunately this server needs to be able to receive data messages up to
> 250k of size in JSON format, so {packet, 2} is not an option.
>
> Is my only option to set {packet, raw} and run a streamed json parser, or
> is there another way to limit the amount of data in some other way?
>

Your JSON data is unlikely to be prefixed the length of the following
payload, is it? So, unless you have another way of knowing the payload
size, you only option is the stream parsing.
I you have any influence on the transport protocol, why not switch to HTTP
or better HTTP/2?

Regards,
Andreas


> Thank you,
> r.
>


-- 

Andreas Schultz

-- 

Principal Engineer

t: +49 391 819099-224

------------------------------- enabling your networks
-----------------------------

Travelping GmbH
Roentgenstraße 13
39108 Magdeburg
Germany

t: +49 391 819099-0
f: +49 391 819099-299

e: info@REDACTED
w: https://www.travelping.com/
Company registration: Amtsgericht Stendal
Geschaeftsfuehrer: Holger Winkelmann
Reg. No.: HRB 10578
VAT ID: DE236673780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200417/448b429a/attachment.htm>


More information about the erlang-questions mailing list