The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"recv/send"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"recv/send"
Сообщение от Cker Искать по авторуВ закладки on 19-Окт-02, 22:48  (MSK)
Эти функции в качестве буффера требуют массив символов. А как быть, если я хочу к примеру, чтобы эта функция принимала/передавала переменные типа integer?
  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "RE: recv/send"
Сообщение от Hurricane_postavil_BSD_i_poka_ne_nastroil_russian emailИскать по авторуВ закладки on 20-Окт-02, 02:03  (MSK)
>Эти функции в качестве буффера требуют массив символов. А как быть, если
>я хочу к примеру, чтобы эта функция принимала/передавала переменные типа integer?
>

First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or FGETS FPRINTF.
You cant send integer pointer to socket, convert to char and send it;

ex: fprintf(sock,"VAL=%d",(int)5);

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "RE: recv/send"
Сообщение от joker Искать по авторуВ закладки on 21-Окт-02, 16:16  (MSK)
>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>FGETS FPRINTF.

а почему ? Это влечёт какую-то опасность??
действительно интересно узнать. Первый раз об этом слышу.

>You cant send integer pointer to socket, convert to char and send it;
>ex: fprintf(sock,"VAL=%d",(int)5);
можно объявить
char buf[sizeof(int)];
int *int_buf=new int;
buf=(char*)int_buf;


  Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "RE: recv/send"
Сообщение от Huricane_nastroil_russkiy_yazik emailИскать по авторуВ закладки on 21-Окт-02, 16:21  (MSK)
>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>FGETS FPRINTF.
>
>а почему ? Это влечёт какую-то опасность??
>действительно интересно узнать. Первый раз об этом слышу.
>
>>You cant send integer pointer to socket, convert to char and send it;
>>ex: fprintf(sock,"VAL=%d",(int)5);
>можно объявить
>char buf[sizeof(int)];
>int *int_buf=new int;
>buf=(char*)int_buf;

Да передать то можно как угодно :) не суть.
Я имел в виду то, что не надо юзать recv/send - это уже история.

Regards,
Vladislav.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "RE: recv/send"
Сообщение от vnp emailИскать по авторуВ закладки on 23-Окт-02, 12:42  (MSK)
>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>FGETS FPRINTF.
>>
>>а почему ? Это влечёт какую-то опасность??
>>действительно интересно узнать. Первый раз об этом слышу.
>>

>Да передать то можно как угодно :) не суть.
>Я имел в виду то, что не надо юзать recv/send - это
>уже история.

Это в самом деле интересно. До сих пор я сталкивался только
с обратной ситуацией -- don't use read/write (for portability
reasons). Что такого плохого с send/recv?

>Regards,
> Vladislav.


  Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "RE: recv/send"
Сообщение от Huricane emailИскать по авторуВ закладки on 23-Окт-02, 13:12  (MSK)
>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>FGETS FPRINTF.
>>>
>>>а почему ? Это влечёт какую-то опасность??
>>>действительно интересно узнать. Первый раз об этом слышу.
>>>
>
>>Да передать то можно как угодно :) не суть.
>>Я имел в виду то, что не надо юзать recv/send - это
>>уже история.
>
>Это в самом деле интересно. До сих пор я сталкивался только
>с обратной ситуацией -- don't use read/write (for portability
>reasons). Что такого плохого с send/recv?
>
>>Regards,
>> Vladislav.

Дыкть, portability не под unix, т.к. под виндой только send/recv можно юзать, а под unixами все портабле. Send/recv галимые функции, старые уже, их использовали раньше, а сокет - это по сути файловый дескриптор, зачем над ним извращаться этими sendами ??? С ними тока жопу морочить.

Regards,
Hurik

  Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "RE: recv/send"
Сообщение от Cker Искать по авторуВ закладки on 23-Окт-02, 23:33  (MSK)
А как быть, если, к примеру, мне надо отправить/получить массив слов:
array [1..1000] of Word; - на паскале.
?????
  Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "RE: recv/send"
Сообщение от hurricane emailИскать по авторуВ закладки on 24-Окт-02, 10:44  (MSK)
>А как быть, если, к примеру, мне надо отправить/получить массив слов:
>array [1..1000] of Word; - на паскале.
>?????

Про паскаль не знаю :(
Если массив динамический типа char **, то ты его не передашь никак, я думаю. Можно определить свой тип данных, и шуровать его через сокет, как в си, imho

Regards,
Vlad

  Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "RE: recv/send"
Сообщение от Dvorkin emailИскать по авторуВ закладки on 29-Окт-02, 17:32  (MSK)
>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>FGETS FPRINTF.
а если сокет "сырой", или, например SOCK_PACKET?

>>>
>>>а почему ? Это влечёт какую-то опасность??
>>>действительно интересно узнать. Первый раз об этом слышу.
думаю, лучше об этом и не слышать - зря не смущаться. :)

>>>
>
>>Да передать то можно как угодно :) не суть.
>>Я имел в виду то, что не надо юзать recv/send - это
>>уже история.
??? :)

>
>Это в самом деле интересно. До сих пор я сталкивался только
>с обратной ситуацией -- don't use read/write (for portability
>reasons). Что такого плохого с send/recv?
с ними все отлично, уверяю тебя. :)

Честно говоря, сам я не пробовал так делать, как ты - не приходилось.
Однако, замечу...
int recv( int s, void *buf, size_t len, int flags);
аналогично send... void *buf - не просто так.
вообще, гарантия 99% что так ты пошлешь все правильно.
Я когда не знаю - просто пробую. :)
вообще, recv/send понимает конец передачи не по Нулю, а по событию в сокете.
Ему должно быть без разницы, что слать.

А, не, простите, делал...
Я загонял чиселки в буфер (побитно) и отсылал их. И ниче... Нормально.
Кстати, именно так и делает ICQ при отсылке/получении сообщения.
Просто надо аккуратно буфер этот разбирать/собирать... Сам понимаешь.

>
>>Regards,
>> Vladislav.

WBR, Dvorkin

  Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "RE: recv/send"
Сообщение от Hurricane emailИскать по авторуВ закладки on 29-Окт-02, 17:51  (MSK)
>>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>>FGETS FPRINTF.
>а если сокет "сырой", или, например SOCK_PACKET?
>
>>>>
>>>>а почему ? Это влечёт какую-то опасность??
>>>>действительно интересно узнать. Первый раз об этом слышу.
>думаю, лучше об этом и не слышать - зря не смущаться. :)
>
>
>>>>
>>
>>>Да передать то можно как угодно :) не суть.
>>>Я имел в виду то, что не надо юзать recv/send - это
>>>уже история.
>??? :)
>
>>
>>Это в самом деле интересно. До сих пор я сталкивался только
>>с обратной ситуацией -- don't use read/write (for portability
>>reasons). Что такого плохого с send/recv?
>с ними все отлично, уверяю тебя. :)
>
>Честно говоря, сам я не пробовал так делать, как ты - не
>приходилось.
>Однако, замечу...
>int recv( int s, void *buf, size_t len, int flags);
>аналогично send... void *buf - не просто так.
>вообще, гарантия 99% что так ты пошлешь все правильно.
>Я когда не знаю - просто пробую. :)
>вообще, recv/send понимает конец передачи не по Нулю, а по событию в
>сокете.
>Ему должно быть без разницы, что слать.
>
>А, не, простите, делал...
>Я загонял чиселки в буфер (побитно) и отсылал их. И ниче... Нормально.
>
>Кстати, именно так и делает ICQ при отсылке/получении сообщения.
>Просто надо аккуратно буфер этот разбирать/собирать... Сам понимаешь.
>
>>
>>>Regards,
>>> Vladislav.
>
>WBR, Dvorkin

Как велик и могучь язык Си ....

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру