WEBVTT 00:00.000 --> 00:19.600 Thank you for coming to see my presentation, I'm pretty excited to be here again and I've always 00:19.600 --> 00:27.800 agreed time at both of them so first slide we miss your answer yeah here's a little bit 00:27.800 --> 00:35.000 next time we're definitely going forward but anyway this is a little agenda so we'll go with 00:35.000 --> 00:44.400 a little stuff and then slide about me so you can read a pretty normal again I'm 00:44.400 --> 00:53.400 been in voiceover IPC pass since about 2003 I read some tools and many of you 00:53.400 --> 00:57.920 have probably heard that for you stuff like article production that helped 00:57.920 --> 01:06.040 around that we've already built our answer part and all the stuff so 01:06.040 --> 01:14.400 switches we have customers and pretty much every place in the world yeah so basically 01:14.400 --> 01:23.120 in terms of free enough for some software we will always think about it as not 01:23.120 --> 01:30.080 what but very much for software can do for us but what we can do for a concert so we 01:30.080 --> 01:36.360 really stop that we find useful and things that might be useful for others so we 01:36.360 --> 01:44.200 contribute public last issues and also a bunch of projects I want it to list it 01:44.200 --> 01:57.560 but it's too long anyway so yeah I'm pretty happy I'll do this stuff anyway so basically 01:57.560 --> 02:03.560 yes I said we built some super search switches with my basic to focus is on 02:03.560 --> 02:12.560 reliability and also obviously care about security and performance so yeah and 02:12.560 --> 02:21.560 as part of what kind of how I can with this project is pretty kind of long story since 2006 02:21.560 --> 02:27.560 we started developing our software and we needed some some kind of system which would 02:27.560 --> 02:35.320 basically help help our components to connect to the right database so we have like 02:35.320 --> 02:44.800 hotstand by a master and basically we can somehow basically can hook it up to to the right one 02:44.800 --> 02:51.360 we do not want to repeat every single like an age component have its own logic to kind of pick 02:51.360 --> 03:00.160 up so we can implement it local like a another service which would basically do like 03:00.160 --> 03:07.440 pull in a database it will pick the right one and expose like to the customer to the 03:07.440 --> 03:15.840 applications and basically how it works we have this control logic which pulls the database 03:15.840 --> 03:22.080 and checks which one is alive and then we have it can spin a number of forwarders which 03:22.080 --> 03:29.680 is just proxy, proxy process basically data without any hook in this event so basically 03:29.680 --> 03:35.760 just very dumb forwarder and it worked very well I was quite surprised but I think it was before 03:35.760 --> 03:43.200 maybe a PG pull was invented but anyway for us it worked very well in the webstreet 03:43.200 --> 03:48.720 here we once saw it's a control logic and Python but we eventually replace the 03:48.720 --> 03:55.840 section of forwarder with some some treatment in C so for performance and then 03:55.840 --> 04:02.880 all kind of as we developed our application it kind of became started like bringing it 04:02.880 --> 04:08.880 apart so basically it became like kind of dug-off micro service which is pretty much 04:08.880 --> 04:16.880 communicate over RPC local RPC mechanism which in our case we use pre-RPC 04:16.880 --> 04:23.840 both basically of a historic RPC we started with XML RPC but then we tried to eliminate 04:23.840 --> 04:30.560 all the overhead because XML RPC runner HTTP so wanted some sense that can run like 04:30.960 --> 04:38.000 on a roll socket and I think JRPC was not even for my B2 was but the drift was the best option 04:38.000 --> 04:44.320 maybe still is pretty fast product all the same ideas JRPC you got your parameters 04:44.320 --> 04:52.720 you serialize them you got response you did serialize them yeah so it works very well so 04:52.720 --> 04:58.640 as I said with all those interactions we can have small-to-bomb interactions between 04:58.640 --> 05:04.160 services we can complete the call basically from mental out in like just a few 05:04.160 --> 05:13.920 milliseconds but now as we kind of grow bigger basically now is a question how we can 05:13.920 --> 05:19.360 scale it up and make it distributed so now we have all those different components 05:19.360 --> 05:28.000 they need to talk over network and this is all problems because as I said we are 05:28.000 --> 05:33.680 running on local circuits so we have some security at least in terms of which 05:33.680 --> 05:39.280 user can access which service and all that with a network we would need like firewall 05:39.280 --> 05:45.920 and multiple ports for each application so it becomes a little bit of challenge so 05:46.720 --> 05:52.640 want to have some better medium mechanism to connect those applications without 05:52.640 --> 05:59.120 any extra overhead like put in like HTTP front end or something so we still want those 05:59.120 --> 06:09.920 applications to talk directly and yeah I've talked around on the risa RFC 41 45 which is basically 06:10.880 --> 06:20.800 specifies how you can negotiate TCP sessions over over as DP basically over CIP and it's actually 06:20.800 --> 06:27.600 funny because if you think about it TCP connection is really like a lot like a phone call so 06:27.600 --> 06:33.040 basically it kind of makes sense in a way actually if you look at the poor minds of even 06:33.040 --> 06:39.120 like to make a TCP connection you need to call function which called dial so to speak 06:39.920 --> 06:46.000 anyway so we still have the original like a initial idea so instead of having like 06:46.000 --> 06:52.720 so let's say application to component to application to most of the talk this component on 06:52.720 --> 07:01.600 this node it can issue basically invite and then negotiate TCP session directly to 07:01.680 --> 07:09.760 that app which runs on local sockets so basically it never realizes that it's too 07:09.760 --> 07:16.000 too remote system and it's really kind of implemented some proof of concept and court 07:16.000 --> 07:22.640 well and then I started thinking how maybe make it even more useful to basically so we don't 07:22.640 --> 07:29.280 need to implement CIP and also as components so we still want them to be a simple and as 07:31.040 --> 07:37.600 small as possible and very very dear basically next idea is something that I call portal so 07:37.600 --> 07:45.520 basically we create a local socket on on the client node and it basically several listens on it 07:45.680 --> 07:53.920 it has to be pretty much similar up to their ones to talk to up for it will open that socket 07:53.920 --> 08:00.880 connect to it essentially and it will initiate CIP session to the CIP 08:00.880 --> 08:07.600 maximizer instance on that as of node and eventually establish the TCP connection between 08:08.480 --> 08:14.960 between them and with part about it that we don't really need to modify 08:14.960 --> 08:21.760 newer client application or several application they basically still talking to local socket 08:21.760 --> 08:28.000 and this one is getting a local connection or local socket too it also could be 08:28.000 --> 08:36.240 very perform because with a lot of this latest latest cameras you can use something like 08:36.240 --> 08:42.160 splice so essentially you won't need to this lahy essentially we'll be short cut in 08:42.160 --> 08:51.760 the internal so you don't need you won't need any even overheading perform like this and 08:52.960 --> 09:02.880 yeah this is a pretty much very easy for us to connect this application with this 09:03.520 --> 09:11.920 it provides unified authorization and application layer because we can use like normal CPE 09:11.920 --> 09:16.720 pretty cool and as you said it should work with any product also you can connect like that 09:16.720 --> 09:25.520 base some some some GRPC or some other binary product all together pretty much anything 09:26.080 --> 09:33.920 so yeah need that plan set this open source I think and maybe we will have goal and 09:33.920 --> 09:45.520 there's some point it's on documentation yeah some of some future ideas for this we can 09:45.520 --> 09:51.920 we can also do some interesting stuff so for example we can we can do like a connection pool 09:52.480 --> 09:58.560 so if you have multiple clients that want to on the nodes that want to talk to one 09:59.120 --> 10:04.560 particular server on remote mode we can pull the connection so you can only have one connection 10:04.560 --> 10:12.640 going and and basically reduce latency even faster because then you don't have connection 10:12.640 --> 10:19.680 it's already as I already just given it run and it's not in use obviously you can we can put 10:19.680 --> 10:26.640 like encryption and compression on on the network layer you can have redundancy and 10:27.360 --> 10:33.280 fill-over and we can also have like product all over for others we wish will basically be 10:33.280 --> 10:42.560 probably like a precondition to those of us above yeah and that's about it so set will be 10:42.560 --> 10:49.120 probably talking about this at some other events in the future but yeah stay tuned we'll 10:49.360 --> 10:52.080 remind the shit 11:13.320 --> 11:16.160 Because we want we want more for the longest latency of a star 11:16.160 --> 11:26.160 So we don't really want any protocol on top of it unless it's necessary, so it's like 11:26.160 --> 11:40.160 kind of goals like this. 11:40.160 --> 11:47.960 Actually, in this case, we actually have two modes of connections, so you can use 11:47.960 --> 11:52.160 your connector, or you can have several connect to you. 11:52.160 --> 11:57.160 And I think I have not really thought about it for us right now, we deploy them like 11:57.160 --> 11:59.160 private networks mostly. 11:59.160 --> 12:05.160 So we have not really got a lot of synchonym to how it's going to work over internet 12:06.160 --> 12:11.160 but there are a lot of connections, and it's kind of interesting. 12:11.160 --> 12:13.160 It might also have interesting applications. 12:13.160 --> 12:18.160 You can even, for example, imagine you have service or I'm in some sort of like 12:18.160 --> 12:20.160 broker and you don't need to expose any ports. 12:20.160 --> 12:25.160 You just need one port and you can have number of applications and you can be 12:25.160 --> 12:30.160 sick to call any of them without an export and because then, 12:30.160 --> 12:33.160 you can connect them to you, not you, to server. 12:33.160 --> 12:45.160 So some stuff like that, but yeah, basically, we'll see how it works. 12:45.160 --> 12:48.160 No, no, the IP is just normal text. 12:48.160 --> 12:55.160 No, I know, but we couldn't do something like a proxy for it. 12:55.160 --> 12:59.160 Yeah, yeah, yeah, can use some service. 12:59.160 --> 13:04.160 But in this case, our server is also proxy, because it's actually endpoints. 13:04.160 --> 13:08.160 So it can be like, whatever you can use, some external. 13:08.160 --> 13:10.160 So yeah, definitely. 13:11.160 --> 13:16.160 Thank you. 13:16.160 --> 13:18.160 Thank you.