CC BY
6Входной поток газа закручивается в лопатках неподвижного завихрителя 1, далее закрученный поток ускоряется до сверхзвуковой скорости в сверхзвуковом сопле Лаваля 2. В таком сопле газ разгоняется до скоростей превышающих скорость распространения звука в газе, где за счет расширения падает его давление и температура, далее проходя через сужающуюся часть сопла (Ркрит)скорость газа резко возрастает . При этом за счет перехода части потенциальной энергии потока в кинетическую энергию происходит сильное охлаждение газа. Далее закрученный поток газа поступает в рабочую секцию 3, в которой происходит конденсация целевых фракций природного газа и воды. Образующиеся капли за счет центробежных сил, обусловленных закруткой потока, двигаются к стенкам рабочей части. На выходе из рабочей части формируется центральное ядро потока, очищенное от целевых фракций, и пристеночный двухфазный пограничный слой, состоящий из жидкости (углеводородов и воды) и газа, и отброшенный к периферии более тяжелый компонент выводится из сепаратора посредством щели образованной диффузором 5 и рабочей секцией 3.
Список литературы
1. Андреев О.П., Минигулов Р.М., Корытников Р.В., Багиров Л.А., Имаев С.З. Технологические схемы УКПГ на основе 3S-технологии для северных нефте-газоконденсатных месторождений. [Текст] // Наука и техника в газовой промышленности, 2009. № 2. С. 4-10.
2. Берлин М.А., Гореченков В.Г., Волков Н.П. Переработка нефтяных и природных газов. Москва: Химия, 1981. 472 с.
3. Берлин М.А. «Неудобный попутчик» // Сфера. Нефть и газ, 2013. № 1. С. 90-92.
4. Гриценко А.И., Истомин В.А., Кульков А.Н., Сулейманов Р.С. Сбор и промысловая подготовка газа на северных месторождениях России. Москва: ОАО «Издательство Недра», 1999. 473 с.
GOOGLE CLOUD MASSAGE ON IOS Quynh H.1, Thao L.2, Hieu L.3, Khoe N.4, Thuong T.5, Hang T.6
1Quynh Ho Van - Master's Degree Student, DEPARTMENT OF COMPUTER SCIENCE AND CONTROL SYSTEMS, FACULTY OF CONTROL SYSTEMS AND ROBOTICS; 2Thao Le Duc - Student, DEPARTMENT OF GEOINFORMATION SYSTEMS, FACULTY OF INFOCOMMUNICATION TECHNOLOGIES; 3Hieu Le Van - Student, DEPARTMENT OF SECURE INFORMATION TECHNOLOGIE;
4Khoe Nguyen Huu - Student, DEPARTMENT OF SECURE INFORMATION TECHNOLOGIES; 5Thuong Tran Thi Mai - Student, DEPARTMENT OF COMPUTER SYSTEM DESIGN AND SECURITY, FACULTY OF INFORMATION SECURITY AND COMPUTER TECHNOLOGIES; 6Hang Tran Thuy - Student, DEPARTMENT OF IT IN THE FUEL AND ENERGY INDUSTRY, FACULTY OF LASER AND LIGHT ENGINEERING, ITMO UNIVERSITY, SAINT PETERSBURG
Abstract: we know that service Google Cloud Messaging (GCM) is needed to ensure that your application always shows the actual data to the user. The scheme of service includes three components. Directly GCM server, your push server and device installed application. The algorithm works is simple: the device is registered in the GCM, gets RegistrationID - a token that is used in the future - saves it from itself locally and transmits the server. Then push server uses this registrationId to send messages to your application on the device.
| 17 I СОВРЕМЕННЫЕ ИННОВАЦИИ № 2(16) 2017
Keywords: server, user, notification, device, service, app, feature.
So as you might know by now, you can use Google Cloud Messaging (GCM) to send notifications to iOS devices through APNs. Let's discuss about what we can do with GCM on iOS in this article. When you send a notification through APNs, it requires two important pieces of information. First is the device token, which is basically an alias for the device you want to talk to. Remember, that's like the secret fake name rock stars leave at the hotel register so that their real friends can find them. Second is the APNs certificate, which basically contains a public key that you can use to communicate with APNs. Oh yeah, and there's the notification itself. So I guess that's three pieces of information. Now, sending notifications through GCM is similar, but not quite the same. Let's look at the two pieces of information you need to send a notification through GCM. First is the registration token. Like the APNs device token, it's the address of the device you want to talk to. Or I guess more accurately, it's the fake rock star alias for the device you want to talk to. Now, GCM has its own token that it uses, but it turns out there are other services, not just Cloud Messaging, that could theoretically use this token, as well. So while you'll often hear it referred to as a GCM registration token, its real name is an instance ID token. And when it gets down to implementing this thing for reals, you're going to see that you'll be using a library called the Instance ID Library to get one of these. Now second is the API key. You don't need a certificate with its own private/public key combination to communicate with GCM servers the way you do with APNs. Instead, you send across an API key that is unique to your application with every request that you make. This API key is generated by the console when you first set up your project, and is what GCM uses to confirm that you really are communicating on behalf of your application, which means this is something you want to treat with the same kind of sensitivity as a password. Don't make it easy for people to discover. Don't put it in a public file on a server somewhere. And for crying out loud, don't ever put this on your client [1].
So if we were using GCM to make a request to an Android device, it would look pretty similar to the APNs flow. Our server would talk to GCM using the API key as proof that we're really who we say we are. Then, we'd use the registration token to both find the right device to talk to, as well as prove that we really have the right to talk to this user because they gave us their rock star alias. Add on the rest of our data, and our notification gets sent. But we're dealing with the iOS world, where things are slightly different. GCM still needs to route all of its requests through APNs if we want to bring up any kind of notification in the background or anything. So before you ask GCM to create a registration token for you on iOS, you first need an APNs device token. Then, you tell Google servers, that: "hey, here's an APNs device token. Can you create a GCM registration token associated with this APNs token, and then send me a copy". This is probably inaccurate, but I like to think that, when you're done, there's a database table out there somewhere that now has your GCM registration token, your APNs device token, and your sender ID all in a row. Now, also remember that GCM, like any other server, needs an APNs certificate to communicate with the APNs service. So at around the same time you register your application with GCM and you create your API key, you're also going to upload your APNs certificate to Google servers to tell it that this is the APNs certificate that it should associate with its GCM key. Again, probably inaccurate, but I like to think that, in another database table somewhere, there's a row that's got your GCM API key, your APNs certificate, and your app sender ID all in a row. So at some point when you're first building your app, you register with the APNs servers using iTunes Connect. You tell it about your app, your bundle ID, and you generate your APNs certificate. Then, you go ahead and register that same app with GCM using the console.
Now at this point, you're going to get back an API key, which you'll use to identify your app to GCM when you talk with it. Now at some point, quite possibly the same time you're creating this API key in the first place, you're also going to upload your APNs certificate to
COBPEMEHHblE MННОВАЦMM № 2(16) 2017 | 18 |
GCM servers. GCM then associates that certificate with the app that is identified by that API key that it just gave you. So now let's move on to the worlds of the client, and what happens when it asks to receive some notifications. First off, your client will tell iOS: "I want to receive notifications". iOS will ask the user if that's OK. Now, if the user says yes, iOS registers your app with its servers and gets back an APNs device token, that it shares with your app. Your app then needs to ping the instance ID service which, for simplicity and because I'm running out of room here, we'll pretend is a part of GCM for its registration token. And as part of the request, it passes along the device token that it just got from APNs. The instance ID service then returns a registration token, and that is the token you're going to use if you want to send a message to this target device. So registration is done. Let's see what happens when we now want to go ahead and send a notification. Now in our scenario, let's assume you want to ping this individual device and you have a little bit of code on your server to do it. For that to work, the user's client will now need to send back this registration token to your server. How you do that is kind of up to you. So when you want to send a notification to this device, your servers are going to send off a notification request to the GCM servers. Now it's going to pass along the API key and the GCM token for this device along with that notification. GCM servers are going to verify that the API key and the registration token both exist on its servers, and it's going to make sure that they both correctly map to the same app. Assuming all that's good, it will then notice, this registration token contains an entry for an APNs device token. That's its cue that our target device is actually an iOS device. So it'll grab that, along with the APNs certificate associated with the API key, and use those two bits to communicate to Apple servers. It will then take your notification request, alter it a bit to fit Apple's notification format, and then send that notification request to APNs along with the device token that it found earlier. Apple will receive this information, confirm that everything looks correct on this end, and then send the notification along to the user's device [2].
All right, well that was an awful lot of work just to send one little notification, right? But don't worry too much of this work is setup stuff that you're only going to need to do once per app, and a lot of the other work really just gets taken care of automatically for you behind the scenes. Now granted, I haven't talked yet about things like upstream messaging which is a whole other kettle of fish or topic messaging or some other edge cases, but I think, for the purposes of getting started with GCM on iOS, this is probably everything you need. So with this information under your belt, I suggest you now go and tackle the documentation, if you haven't yet. It'll probably be a little easier to digest now that you have some background information.
References
1. Google Cloud Messaging: Overview. [Electronic resource]. URL: https://developers.google.com/cloud-messaging/gcm/ (date of access: 23.11.2016).
2. Setting up a GCM Client App on iOS. [Electronic resource]. URL: https://developers.google.com/cloud-messaging/ios/client/ (date of access: 27/10/2016).
| 19 | COBPEMEHHblE MHHOBA^M № 2(16) 2017
