512 entries in 0.645s
a111: Logged on 2018-09-18 18:03 ave1: I was working towards having different modules on top of a common base to support
tcp / unix sockets etc. but I think your idea is way better, asciilifeform
http://btcbase.org/log/2018-09-18#1851315 a111: Logged on 2018-09-18 16:06 asciilifeform: as for
tcp, unixsockets, etc. imho if we ever need these, they oughta live in own separate lib, given as they force somewhat different and gnarlier semantics, they do not belong in 1 gigantic 'kitchen sink' imho
a111: Logged on 2018-09-17 08:00 ave1: I'm aiming at a small library with support for UDP,
TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done.
diana_coman: ave1> I'm aiming at a small library with support for UDP,
TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done. -> mind publishing somewhere this part then?
ave1: I'm aiming at a small library with support for UDP,
TCP and UNIX sockets with direct calls to 64bit x86 and 64bit arm plus C. So far UDP + asm 64bit x86 is done.
☟︎ diana_coman: hm, so basically there might be something to "only
tcp on gnat.sockets" after all since they baked this assumption in the...implementation of gnat.sockets themselves??
a111: Logged on 2013-03-11 07:17 mircea_popescu: actually the plan was to have
tcp/ip reimpremented over pigeons
mircea_popescu: you don't really gain so much by having your special packets encapsulated in
tcp phf:
http://btcbase.org/log/2018-08-20#1843300 << little known fact: slime's architecture was originally implemented in a similar project for erlang called distel, by the same author luke gorrie. lukego also wrote an emacs clone in erlang and
tcp/ip stack in cmucl.
☝︎☟︎ a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1
tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
spyked: hm. so trinque, OTPs don't have any sort of expiration? the scenario I'm thinking of is that eventually my (for example) home ISP would do some stupid thing that would lead to the
TCP connection going down. but that could happen in a week, a month or six from now, so I'd want that OTP to be valid whenever that happens.
zx2c4: mircea_popescu: let's take a protocol that just encrypts ip packets and nothing more. traffic analysis of the size of packets gives you something, especially in the case of
TCP where there are necessary types of responses at various points. but i suppose you want me to consider "general purpose cases". so im thinking about a raw UDP protocol. in this case, it might be that at the end of an exchange, one side has nothing more to say, and so it says
zx2c4: with many
TCP protocols you can infer what's behind it based on the length
zx2c4: every time i send you something, i expect to hear back from you. if i dont hear back from you, then something bad has happened,and i should start over with a new handshake. my way of hearing back to you might be in the natural sense -- i send a
TCP SYN, you send me back a
TCP ACK -- or it might be the case that you actually just have nothing to send back to me. you got my message just fine, but really just cant think of anything to say back to me.
mircea_popescu: (i don't mean it's the same thing ; i mean it's in the
http because it was in the
tcp.
mircea_popescu: anyway, for the record : nothing in the world fucking easier than socat -u
tcp-1:113,fork system:./say_mp.sh
vlad56324: now with broadband it seems that everyone has the permission to grant the shit out of my pc in terms of
TCP connections
mircea_popescu: so basically they made a thread to "replace" the work the os does with the
tcp stack, for instance.
a111: Logged on 2017-08-21 22:31 asciilifeform: i don't much like the phrase 'trusted nodes', when you connect to trb node, you get plaintext
tcp, and 0 guarantees re who or what you're actually talking to.
ben_vulpes: "the greatest website to ever fit in a single
TCP packet"
mircea_popescu: the equivalent of "no need for flow control" in
tcp/ip say
a111: Logged on 2017-07-20 19:01 trinque: pf: pf_normalize_tcp_stateful failed on first pkt << deedbot departures appear to correspond with this.
trinque: pf: pf_normalize_tcp_stateful failed on first pkt << deedbot departures appear to correspond with this.
☟︎ a111: Logged on 2017-06-30 07:41 sina: can change
tcp for udp, can change sql for flatfile, can change python for syslang
sina: can change
tcp for udp, can change sql for flatfile, can change python for syslang
☟︎ sina: I was thinking about the latest iteration which is much simpler, I think I might try and convert the
TCP bit to UDP tomorrow
sina: tmsr trigger warnings: it uses sqlite,
TCP, OOP but I tried to make it modular enough that those things could easily be changed. It isn't the lighthouse or linespeed thing asciilifeform has mentioned, I just tried to follow the spec on trilema.com
trinque: what you've got there looks like a
tcp-gpg-wad hucker
Framedragger: i guess no way to use luby code or equivalent on
tcp huh
jurov: idea: what about providing fuckgoat output in realtime, as
tcp stream. maybe i'll do when i get some
mircea_popescu: dude, what the fuck is with the bullshit. "we made a
tcp on top of
tcp because we're bored at "work" and hurr."
mircea_popescu: "Unlike
TCP, the service mesh has a significant goal beyond just make it work: it provides a uniform, application-wide point for introducing visibility and control into the application runtime."
Framedragger: that's why i preluded with "if backend connects over
tcp"
a111: Logged on 2017-03-14 14:07 Framedragger: mircea_popescu: re. blackholing and to be alf-pessimistic for a second, node is exposed to risk of being blackholed as long as it uses
TCP; because not only can enemy make it read packets (unavoidable in the end it seems), but there may be ways to making it send packets back.
Framedragger: (i guess "silently drop connections" (
TCP DROP) from any non-whitelisted IP is one way around it, sorta.)
Framedragger: mircea_popescu: re. blackholing and to be alf-pessimistic for a second, node is exposed to risk of being blackholed as long as it uses
TCP; because not only can enemy make it read packets (unavoidable in the end it seems), but there may be ways to making it send packets back.
☟︎ Framedragger: mircea_popescu: the 20M or so servers which responded to
TCP SYNs sent to port 22. however, out of those, about 5M (or however many) did not respond to ssh handshakes, hence the lower number in the banners and phuctor payloads.
Framedragger: (oh oh, and also trying out masscan (the first-stage scanner, i.e. the one which sends
TCP SYNs) with maybe 30-100k packets per second stable))